How do I simulate "Wish List" and "Bug List" in JIRA workflow?

How do I simulate "Wish List" and "Bug List" in JIRA workflow?

Should they be states, or resolutions?

3 answers

1 vote
Thomas Schlegel Community Champion Jul 31, 2012
In my opinion, these should be different issue types. Errors and Features.

We create different issue types for these and each type has their workflow.

1 vote

These sound like different issue types to me.

Representing them in the workflow feels like nonsense - what would be the point of having an item that has status like "bug", "nice to have" and being able to swap between them as part of the workflow?

Having different fields and workflows for the different issue types really does work well though, and setting up something where customers/end-users raise "issues" in one project (without firmly pre-judging what they are because customers often don't know whether it's a bug, a new feature or something else) and having a process where your developers/product-teams triage them over into another project (changing the issue type to the right one on the way)

In our company, these are treated as different projects, as they follow very different timelines. Bugs need to be fixed before the product goes live (at least the critical ones) whereas "enhancements" need to be sized and slated for upcoming releases.

"Wish List" and "Bug List" issues start as regular bugs (or features). They end up on the bug list/wish list after being resolved as Won't Fix. For example this bug will not be fixed in the next release. We don't know in which release in will be fixed.

We also triage. But, then just move the issue to the appropriate issue type and/or project to put into the correct queue and workflow.

We have a transition and state that is Backlogged or you can use something like Scheduled if you are going to work on it right away. Basically, we will move these enhancement or bug requests to a backlogged state and unresolved and then once they are pulled into a version for a release, then they are moved in to a started or in progress state. We have some other states while in backlog such as ready for grooming (all requirements and criteria defined) and groomed (means it has been story pointed or estimated and ready to pull into a version/sprint).

We never resolve them unless they are done, we never plan to fix, or they are a duplicate.

Then I would agree with the pervailing wisdom that issue types makes the most sense. For us, we typically "triage" issues before entering them, so we know up front whether they're bugs or "wish list" items.

Thomas Schlegel Community Champion Jul 31, 2012

@ isobretatel: do you think resolving them as "Won't fix" is the right way ? In our Jira, "Won't fix" means, that the issue will never be fixed, not in the next release and not in any future releases.

If we don't know, when an issue will be fixed, we do not resolve it.

It does sound like your resolutions aren't being used in a good way. If something is resolved-won't-fix, that really should mean "we are not going to work on this again, there's nothing we can/will do". If it's really going to get looked at for a later release, I don't think it should be resolved at all.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,098 views 4 9
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