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

This widget could not be displayed.

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
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Wednesday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

112 views 2 0
Join discussion

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