We need the ability to exclude statuses from the to do, in progress, and done.  We have another bucket for cancelled. Cancelled needs to be excluded from our reporting.  For example, we have a status of deprecated.  We need to exclude from all future reporting based on the status category of cancelled.  We all have another status of future enhancement.  For our task purposes, this is considered cancelled and don't want it in our counts to work from.

Wow this kind of stinks. I don't use any of the default statuses like todo, in progress or done. I've made my own categories because these three do not work for me. What a shame that you have arbitrarily locked me into a non ideal scenario because of some color scheme style guide. 

This is really obnoxious. The only flaw in my use of Jira right now is that when I make a timeline out of my main project board, all of the timelines have the same color because they are indicative of the status boxes. I would love to color these time line items other ways.. But nope.. Can't.. why? because Jira says so...

This is infuriating. On one hand you say you are making this software to help project managers keep track of things but when we ask for a slight amount of flexibility you block us!? Over a style guide?!?!

BTW, I'm viewing your website via darkreader. Your style guide will never be represented properly on any browser I use ever. So.... great plan. 

Like most software development shops, we have development "in progress"/done, and after a build, QA "in progress"/done. We can either have the green bar represent dev done, in which case QA's status is unrepresented, or we can go green, build, and be back in yellow again for QA. In either case, it's impossible to use JIRA's inflexible system to represent what's actually going on. 

Since this ticket sees so much love, I'll reiterate my professional but independent thoughts ( I don't work for Atlassian ).

The categories split statuses into work not started (or TODO), actively working (or IN PROGRESS), and no work remaining (or DONE). Values like "QA", "Blocked", "Fixed": These are not categories that have any place in the current definition when objectively looking at the existing categories. In fact, I'd say these existing values are the only valid categories you could define to categorize a status. The status represents WHERE the issue is, not what happened. Breaking the statuses into categories like BLOCKED or QA is NOT well thought out and would not be easily applicable.

As someone who has made a career out of successfully deploying JIRA at enterprise scale, I would heavily encourage people to NOT use values like "Blocked" or "Fixed" for statuses. There are better ways to handle it such as Issue Links (blocks/is blocked by) or Custom Fields (Flagged – Impediment).

Constraining the number of categories like this assumes everyone works the same way, which clearly we don't.  To be honest, without the ability to add my own categories these are truly useless.

First off, I want to thank Dave for articulating the reason for not implementing this feature. It makes sense to keep a constraint on the number of categories.

The reason I was looking for this is we don't have our QA assigned to a specific development team, and it most cases, once the ticket hits "Ready for Test" or "Testing" the developer is typically done, assuming there are no issues found by QA. Consequently, we find that sprint reports aren't as granular as we would like to see (Dev is done, QA is pending), and we end up generating reports by hand.

In order to make reporting more useful (end of sprint, and release) it would be VERY NICE TO HAVE one additional category that fits this need.

Thanks for your time!

-Justin Weaver
Software Engineer/ DevOps

Relias Learning

+1

These categories are vague to the point of being useless.  In Progress and Done are nice but what about in testing?  That's neither.  That happens AFTER the work is done.  What about Closed, which is after the work is done and after it's tested? 

This very task could be DECLINED not CLOSED

It's really important for many teams to separate tasks that were really done and therefore closed or skipped for some reason ones

tewr0512366717 I don't using red for Closed since this is essentially an issue that is done. If an issue was not done at all, its not necessarily a bad (usually associated with red) thing as the issue would only be Closed (the Resolution dictating its reason) if it were justified. However, I would like to see a category Called Blocked with either orange or red.