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?
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.