We commonly have issue submissions from our developers or applications engineers for new features (big or small) or feature enhancements that, for one reason or another, we don't plan on working on for a long time. These are things where your reaction is "yeah, that's a good idea, but we won't have time to work on that any time soon".
People like keeping the issues in the system because we may want to do them at a future date.
In our previous issue management system (before switching to JIRA) we used an issue type called 'continuous improvement'. We periodically review all 'continuous improvement' issues to see if they should graduate into real features or bugs and therefore get scheduled and worked on.
Now that we are switching to JIRA I'd like to hear any opinions on the right way to handle these types of issues.
Part of my goal is to keep the issues in the system so that (1) we may find them and work on them later and (2) people don't submit duplicates. However I don't want managers and developers to be burdened with sifting through hundreds of these issues to find the important ones we plan on working on.
Some of my current thoughts:
Have you thought about using a label instead of a new Issue State? I often categorise Issues with labels; Draft, Ready, Customer, and Deferred.
Labels are pretty Flexible and you can change your Kanban board JQL filter to exclude any issues with the label "Deferred". Alternatively you could create a quick filter or swimlane to your board to separate them.
I've blogged about using labels and quick filters for Sprint Planning if you want to adapt it.
That's a fair suggestion, I'll think about it. Off the top of my head, my concern is that labels don't visually stand out enough, and managers / developers may accidentally spend time looking at an issue with a Deferred label. That could be fixed via filters as you pointed out. Thanks.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...
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!
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