How to go about differentiating released code bugs vs work in progress bugs

Hi,

I'm looking for some advice on how to manage our process in Jira. I need a way to differentiate between 2 types of bugs. Basically I want a standard bug for released/shipped code that customers are using and then a secondary way for us to log bugs on 'in-progress code'. i.e. issues with a new feature in a release that has not yet shipped.

The idea is that when a release is shipped our product manager can view only actual bugs fixed and ignore those logged for the new feature whilst it was being worked on.

In our current process we have these logged as 'snags', these are bascally simpler bug forms for quick issue entry on in-progress code. When a project is shipped any of these snags that are unfixed then get moved to the backlog and changed to bugs/improvements.

Any help with how to manage this in JIRA would be most appreciated. We have thought about duplicating the bug form and renaming the copy as snags so we can follow a similar process but wasn't sure if this was the best way? Is it better to have a field/tag on each bug that we can log this instead?

1 answer

0 vote

I think your initial thoughts are absolutely right, although I foresee two little problems with it.  I would create/use two issue types - one called Bug and another called Snag (although if you want a name change, this would be a good time to do it).

The little problems:

  1. Getting your users to use the right one when they create new issues.  You can always move them to the right type when someone does get it wrong, and there may be ways of helping prevent it, or even blocking it, depending on how your exact process maps on to JIRA.
  2. Changing their type later when you flip snags over into the bugs/improvements - can be a bit fiddly, but with the help of a filter and "bulk edit", you should be able to do it reasonably easily.


The good points from going this way are mostly what you've already said.  You'll have clear, reportable, distinguishable issue types to work with.  Probably the one thing that really stood out to me though was that having different issue types allows you to have different workflows and screens for them.  I would do what you've said - get your "bug" screens right, copy them to a new set and then cut down the new ones so that they work for snags.  The reason I'd do it that way is that you don't want to have fields on snags that are not on bugs, because when you come to convert them later, you'll lose the fields.

 

Thank you for your thoughts regarding this. It's good to know that I'm on the right track. Will be interesting to hear if anyone has alternative approaches though. 

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Monday in Jira Software

How large do you think Jira Software can grow?

Hi Atlassian Community! My name is Shana, and I’m on the Jira Software team. One of the many reasons this Community exists is to connect you to others on similar product journeys or with comparabl...

637 views 6 12
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you