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

[Anthony Read]

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?

[Nic Brough -Adaptavist-]

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.

[Anthony Read]

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.