How can I create a status category?

[Alexander Yordanov]

Hello,

Right now there are only 3 status categories - 'To Do', 'In Progress' and 'Done'. I want to create another category and associate it with my own statuses. For example, I don't want the status 'Failed' to be in category 'Done', because that changes the background of the status to green, and is like the request failed as intended. In my case request should be worked on till the status goes to 'Done', but there should be intermediate status failed with the color red.

Regards,

Alexander

[Christopher Jaksch · Accepted solution]

Hi @Alexander Yordanov,

according to https://jira.atlassian.com/browse/JRASERVER-36241 Atlassian won't enable new status category colors.

You could try an add-on (e.g. https://marketplace.atlassian.com/plugins/com.almworks.jira.colors.colors-plugin/server/overview) to improve colors of your issues based on status.

Hope that helps.

Best wishes
Chris (STAGIL)

[Marcello Romani]

I fail to see how this answers the OP question.

"I want to create another category and associate it with my own statuses."

I don't see this issued addressed at all.

Could you confirm whether it is possible at all or not with JIRA cloud? Could it be added by installing a plugin?

Thank you

[Chris Gembarowski]

As much as we hate it, the answer to, "How can I create a status category?" is "you can't."  However the link provides suggestions on how to simulate custom status categories.

From the link:

We have decided to close this specific request for additional status categories as Won't Fix. The finite set of status categories allows us to build useful features on top of them, like completion progress indicators for Epics and Versions.

We recognize that for many teams, most of the steps in a workflow are "In Progress" and that it can be difficult to distinguish them. Here are some strategies:

Add additional columns to your board for different workflow states. You can have several "In Progress" columns to represent concepts like "In Development" or "Under Review".

Use the card colors based on JQL queries feature (documentation) to define your own colors for workflow states. I've created this suggestion in the JIRA Agile project to improve this in the future: GHS-11666

Use JIRA Agile card layouts (new in JIRA Agile 6.6) to show the workflow state on the card (documentation)

To customize the display of issues within the JIRA issue navigator, consider the free third-party icnavigator add-on from Interconcept GmbH.

[Lori Full Access]

I will now cancel my trial period.  I refuse to do a series of workarounds for something as basic as having more than 3 status categories to pick from.  

[James K]

We have decided to close this specific request for additional status categories as Won't Fix.

Ironically, "Won't Fix" doesn't fit into a category of "To Do", "Doing", or "Done" (technically).

[stefano_gregori]

Won't Fix is the Resolution and not the status which probably has been "Rejected"

@Integration Team ... mm this seems a really useful feature especially for user like corporates where you have lot of projects and want to create some view / filter to highlight some important "Phases" in the company lifecycle ... which can have Different Statuses in different projects

[Alexander Weickmann]

We have an interesting use case where it would be

"New" -> "In Progress" (somebody is actively looking at it / deciding what to with it) -> "Handed Over" (an external partner is taking care from now on, users should no longer edit the issue directly in Jira) -> "Done"

Separate status category would have been nice in this case. It would have allowed us to build a workflow condition based on status category. Now we have to explicitly configure all the individual statuses that should be taken into account.

The "building features on top of the 3 basic categories only" could still be achieved, if Atlassian would require that each status category would need to map to one of the original 3 categories.

[mquickenden]

Any progress on having the ability for the users of the application to define their categories?  Seems like everyone who has arrived here wants to be able to add custom rollup status beyond 'to do' 'in progress' and 'done'.  That's why I'm here.  Would love to see the page analytics for this one. my customer has several projects all rolling up and 3 categories just isn't cutting it for them, so they are exporting to excel and manually managing this... meanwhile, I'm saying use the work flow tool for workflows and reporting.  look you can report in there 3 things... not good enough. simply waving your hand trying to pull the Jedi mind trick here, "these arent the categories you're looking for" unfortunately isn't good enough.

[Ben Hoyt]

Agree with previous comments.  If there's some reason that admins can't create new/custom status categories, it would be nice if a few additional obvious ones could be exposed, such as a Red "Blocked/On-Hold" one. The existing categories imply that all issues are either not started, in progress, or finished. But what about ones that have been halted? How should those be categorized?

[Deleted user]

I'm in the middle of creating additional workflows for my program team and can't seem to find any information on how the Status category actually impacts the issues in Jira - other than the colour. 

Our reporting is all run off the actual Status, not the category. I'd be interested to hear how you use the Category?

Thanks

[Lara Bailey]

They are used to automatically track total time spent in each category. All Todo categories are summed up together, as are all In Progress and all Done. The issue is there needs to be a 4th category for Waiting (or as suggested above, Blocked), so we can track time a project is waiting/blocked as well. Todo should be separate as it's not waiting for anything except internal resources, which is important to track as well, but distinct from waiting for something outside of the team's control. 

[Andy Beard]

I definitely agree with the need for a Waiting or Blocked status category.

We have several workflows where issues are essentially sat waiting to be actioned, but there is a difference in my mind between when an issue is waiting for a member of the team to deal with it, and when it is waiting for a customer to do something. 

If something is waiting on a team member for ages, that's a problem we can look at and potentially do something about, but if something is delayed for weeks because a customer or other third party isn't doing their bit then that's something that is effectively out of our hands, blocking any progress.

Not that I expect an additional status category will be added, just wanted to add my thoughts to the thread.

[IndexingAlex]

Even if you don't want to allow users to create their own, we should really have additional standard status category options. As an alternative, just let us use our actual statuses for filtering, etc, and stop using these status categories as a shortcut. Why have extra semantic layers disabling things that should be simple? This kind of needless complication is what I hate most about Jira. 

It's absolutely bonkers that the Backlog is categorized as "To Do." For a huge number of teams, a backlog is not just an extended "to do" list, but includes ideas or requests that are on the table, but have not yet been selected for implementation. This is why YOUR OWN DEFAULT Kanban set-up includes the status "Selected for Development", because the Backlog items might never be selected. Until something has been selected for Development, there is no development to be done for that item--literally, nothing "to do". So it seems pretty obvious to me that "Selected for Development" is the earliest status that should appear in the To Do status category.

This implementation is especially idiotic when looking at our roadmap, where there is no way to exclude issues by status, only by status category. This means our Roadmap either shows our entire Backlog (because it's all To Do, lolz) or else it shows only what we have already in progress or done. This completely defeats the purpose of a planning tool!

So I have to do stupid stuff like categorize "Selected for Development" and "Open" as In Progress, just so I can isolate the Backlog from the rest of our work.

[Stacy Kennedy]

Adding a status change date would be helpful, too. the status category change date is useless when almost every status is in progress

[Daniel Carper]

Why is Google saying this issue is solved? I was so excited when I saw this, but then the accepted answer is that it IS NOT solved.

Every resource, attribute, and property is customizable in Jira, what is the thinking behind not making status categories so?

There are so many more status categories that are so so basic... How about "Blocked" for instance which may have several statuses associated with it? And you need a category to differentiate when a task has not been started (todo) and when it is not able to move forward (blocked)?

Please add this basic feature

[Daniel Beattie]

Here here. This pretty much sums my thoughts up.

[J. Caldwell]

It's solved because the short answer is "You can't." There were suggestions on how to simulate things. That's all you can do.

[Daniel Carper]

Well that's misleading, inefficient, and inconsistent with the plethora of "done" statuses I get out of the box with Jira even.

This is a question (check the breadcrumbs / url), questions have answers... You don't solve a question, you solve a problem. And this is a question concerning a problem that is anything but solved.

I could see an accurate status for the problem itself being Unsolved, Never to be solved,  Decided to never implement. Or maybe change the status of this to at least Answered so it makes sense. Any of which would then have a status category of Done

In a perfect world someone would figure out how to get Google to simply show the text You can't, ever on the search results page and save everyone the time and hassle. 

Anyway just my two cents, cheers

[Jessie Z]

@Daniel Carpenter, your response made my (and my whole team's) day. You articulated our thoughts perfectly.

[aseff1]

Google is saying it's solved because there are only 2 options :) :) :) :) :) 

[Graham Twine _Slm_]

@aseff1 do you mean there are only 2 status categories and not 3?


**ducking** 

[Edwin Orjales]

Because they don't have a "Won't Fix" category to tag this with lol

[David Dykstra]

In our organization we have 5 different categories of tickets and it would be nice if we could have JIRA recognize that.

Planning/Analysis -> To Do (Backlog) -> In Progress -> In Review -> Done

Within those categories we have the following statuses:
Planning/Analysis
(New Idea -> Requirements Analysis -> Stakeholder Review -> Scheduled)

To Do (Backlog)

In Progress

In Review
(QA Review -> Code Complete -> Code Review -> Testing)

Done
(Ready For Release -> Released)

We currently make it work by utilizing multiple boards and manual labor to convert issue types etc... Other larger organization I am sure have other quality assurance processes that require more customization in this area.

Example of where it would be helpful. We use an addon BigGantt to help with the planning of tickets. BigGantt has two task colouring options, Status Category and Manual. I would like to have more that 3 colours, but the colour is assigned to the category and there are only three options. If I could add another category type I would be able to organize my work better.

So big up vote from me to have this configurability. 

[Steven Ventimiglia]

I'm pretty sure that most folks are mistaking a category for a status.

It ruffled my feathers as well, since I didn't understand why "In Review" would be such an impossible category to request and have added.  However, a custom "In Review" status is inherently associated with the "In Progress" category - since the overall intention is to further the progress of an issue being resolved (or marked as "Done").

Hopefully this explanation helps a few folks avoid steam shooting out of their ears.  :D

[JaxCavalera]

How do we explain the missing status category Blocked. It may or may not be getting resolved, it certainly isn't progressing .. so in progress doesn't fit the bill and todo may not cover it when the issue that's blocking it IS in progress.

Something that can be both in progress and todo depending should have a more definitive category that describes it.. a.k.a Blocked.

[bernhard bockelbrink]

Personally I think that flagging and item when it's blocked makes much more sense that having blocked status, because that preserves the position of the item in the workflow, you can add a comment why the item is blocked, and flagged items are highlighted, and can be filtered by a quick filter. 

A separate blocked status would require a transition from each status to the blocked status and back, making it error-prone to return the item to the previous status once the item is unblocked. A flag can simply be removed.

Now if you have a more complex workflow that involves several roles or teams, the blocked status would also need to reflect who is responsible for taking action to unblock the item. How would you make blocked items show up in the right people's dashboard? You'd need to create several blocked statuses, one for each role or team. That complicates things unnecessarily.

[JaxCavalera]

It's significantly easier for teams to visualise and manage blocked issues when they have a blocked status.

All statuses, regardless of status type, need to define workflow transitions. With a blocked status type, there's no guarantee that once resolved, it will always go back to the same status it was previously at so I don't see a need or value in trying to automate this.

It is equally possible that when resolved, it eventuates that the issue gets cancelled or needs to be completely reworked based on how it was unblocked.

The flag system lends to miscommunication where tickets appear to still be in testing or in progress when in reality they are blocked.

Now if you have a more complex workflow that involves several roles or teams, the blocked status would also need to reflect who is responsible for taking action to unblock the item. How would you make blocked items show up in the right people's dashboard? You'd need to create several blocked statuses, one for each role or team. That complicates things unnecessarily.

It seems like a simple scenario to deal with, I'm not seeing the complexity.

1. Assign the ticket to whoever is taking point on it (regardless of their team)
2. Raise an appropriate issue(s) that accurately capture the specifics about the blocker on applicable projects / boards
3. Jira link the original issue as `blocked by` the new one(s)
4. When all linked blocker issues are resolved the status of the original issue can be updated to reflect the final outcome

[mark_faulkner]

Echoing this request. To Do - In Progress - Done  for project status columns is limited. Is it possible to add an additional Category for your project's Status Columns?

[Rafe Sacks]

I want this too. A New issue isn't "To Do" yet in our workflow. It is more like "Requested" or Proposed"

[maarten breesnee]

that can be done easily... you can create a new status and make that the first status when you create an issue.

[Rafe Sacks]

How does your suggestion relate to categories? Our first status is "New" which is custom. However I can not set that to a custom category which is not yet "To Do".

[maarten breesnee]

You question seems workflow related as you mentioned: A New issue isn't "To Do" yet in our workflow. 

So it seems that you want to change your initial status. 

[Rafe Sacks]

That is not correct. There is a status category "To Do". We already have custom status "New". This question is about custom categories. There is no category that fits with our "New" status. The first option is "To Do" (again this is a category, not a status. each status is assigned a category in Jira). We do not want it to be "To Do" because we do not want anyone working on "New" tickets until they are moved to the "To Do" status (which is also in the "To Do" category). We also want to be able to create an "Active Issues" filter that does not include issues with the "New" status. If we add the "New" status to the "To Do" category then it will show up in the "Active Issues" filter. I hope that clarifies things. There is no category that fits our "New" issue status.

[Colin Tennery]

Has there been any update on this bit of functionality? I can't seem to find any way to create your own custom Categories within a Status. The ability to create custom categories and use them as the default categories are used seems like something that definitely should be supported.

[Jeff Davis]

Maarten Breesnee, have you been able to create new status options to assign to your work items? If so, how do you do it?

[Andrey Ivanov]

Well that's a shame there isn't even a default category "Blocked".

Seems as an absolute lack of flexibility.

[Phil M]

Same here - we would love the possibility (flexibility) to add an extra status category,

e.g. To-Do / In Progress Design / In Progress Dev / Done

Why? It will give great insights on the roadmap view, and will allow high level sharing and comprehension where is an epic at. A lot happen during the In progress category (we have (Design, Dev, SIT QA, UAT QA), and could even add more to it. So grouping all that under the In progress blue color isn't super helpful for stakeholders.

Suggestion:

1. Add the flexibility to create additional status categories

2. Able to choose a color (other than blue) for this new category/ies

3. Able to map a status to this new category/ies (already doable)

4. Changes are reflected on the roadmap, and stakeholders are able to identify what is To-Do (grey), In Design [UX/UI/Function Description] (blue), In Development [Dev, SIT, UAT] (X), Done (green).

[Graham Twine _Slm_]

@Phil Mare In Progress Design / In Progress Dev not both in the same "Status Category" In progress. (Doing something)

These are really "Statuses"? (What is being done)

[Michael Ballenger]

Does sound like there's a lot of interest for this as an enhancement.  Was looking for the same thing, as we would like to have separate categories for "In Development" versus "In testing".  While our teams are tracking multiple statuses for development or testing steps, having two separate categories would allow those statuses to be grouped for reporting purposes without resorting to JQL queries etc.

[Deleted user]

Crazy that this isn't a feature, at the very least for accessibility purposes.

[tmaiaroto]

It would at least be nice to see another status or two available. A "Rejected" or "Invaid" of some sort as people are asking for mostly...But also something like "Approved" since Jira really puts you in a position of screwing around with the "definition of done." It's probably the biggest thing that holds Jira back from being a good tool for Scrum.

We either call something "Done" when it's not and completely mess up our velocity and Scrum or we sit here with less useful reports, ugly looking burndown charts, and a general sense of bottlenecking and lack of understanding about status iroincally enough.

[Giselle Abadi]

If this thread is still active, I want to add my voice as an active Atlassian Suite user. We also need more status categories to manage our highly complex project!

A workflow system should be flexible! This is probably the most important criteria of a workflow system that is supposed to handle highly complex software projects!

Please add this feature on top of your Backlog! ;)

[Mounir Haddouch]

You should be able to add, PLEASE RFC!!!!!!!

[Jason Barber]

Would also like to know if we can add to the default "Category" under Statuses or are we simply limited to "To Do, Done, In Progres"

[OA]

At the end there are only three kinds of statusses:

1. To Do
   is everything that needs to be worked on
2. In Progress
   is everything what actively is worked on
3. Done
   is everthing what needs no more work to be done on it

There is no other category beyond this.

If you need a status "Failed", then you have to know what this means if it is in that state:

If, after it fails, no work needs to be done, then the category is Done

If you work actively on a failed status, it would stay in the category In Progress

And if you need to do some work in the future while it is failed,
the status category would be To Do again...

So you see, a failure has nothing to do with a status category, in fact all status categories are possible for a "Failed" status, so a better concept would be - as noted before - a flag.

Another example:

A status "On Hold" most makes sense to be in the To Do category,
because it's not clear if you need to work on it in future or not,
but the decission wether to go ahead working on it or not, is a To Do also...

[Planck Lee(LiJiao)]

“Resolved" status is a "Done" category for RDs, while "Resolved" status is a "In Progress" category for QAs and the whold release.

However, there are only three categories, It can't match the RD's need, then they should build another dashboard manually to see what's the issues that are really in "In Progress" status for different releases, or search manually from the "In Progress" category.

It's really depressing.

[Paul Thomson]

I think the biggest issue with this is that a failed status may have different outcomes, and there is no real way to indicate this visually with colours.

Green signifies "go". A fail should really be red, a fail which could be remedied or repeated could be amber.

These statuses would all be classed as Done and green, and that doesn't make any sense semiotically.

[mquickenden]

.

[Michael Holmes]

At first it was frustrating but thinking about it and the ripple effects to Releases and out of the box Reporting for example it's understandable that Atlassian have made the decision. If you think about it any work item (in or out of work) is either 'To Do', 'In Progress' or 'Done'.  If you want to sub-categorise where something is within those statuses it's entirely possible in JIRA as it is in life.

Build your board(s) based on a filter that doesn't include 'new' as the 'working board', create a board with only the 'New' issues as the prioritisation board to determine what should go into 'To Do'.

Create a Kanban board and using a backlog so that the 'New' issues that aren't selected/prioritised to a 'To Do' status don't show on the (To Do, In Progress, Done) board.

How to do that you ask?

It's possible to create new issue statuses in the workflow section, then when constructing your board you choose whether to assign or not assign those statuses to show up on the board under the 'To do', 'In Progress' or 'Done' columns.

For example you can choose NOT to display 'New' issues on the board, only those that have been transitioned to the 'To Do' status.

Also boards do allow you to create multiple columns to support the desire to break 'To Do' into smaller portions of 'To Do', for example 'In development', 'In code review', 'Ready for Test', 'Ready for Release' can all be a 'To Do' status if you create them as a workflow status, you can then create columns in a board using those statuses, they are all 'In Progress' type statuses.

[Jade Whitla]

Yes there are workarounds. We already recognise this. Doesn't it seem odd to you however, that the To-Do status doesn't belong to the To-Do category in the scheme proposed. I'd call that a smell.

As a side note, the fact that people are searching for how to achieve this objective at all, rather than why it is missing is yet another indication of the incredibly poor UI affordability of recent versions of Jira. I've been a Jira user since the first release in 2002 and I still waste time trying to figure out how to accomplish what should be simple configuration tasks. It sure makes it hard to sell this tool as a contractor to a new management team every few months.

[bernhard bockelbrink]

I am with you that Jira leaves many things to be desired, however I find this set of status categories pretty comprehensive: Each item in any workflow I can imagine is either waiting to be processed (To-Do), being worked on, or finished. I really can't imagine a fourth status category. Atlassian may be doing a poor job explaining this, but the concept is sound.

It's actually quite simple:

• any pull-system relies on work being organised in a series of buffer stages (to-do) and work stages (in progress)
• work in that context means anything that changes the state of an item
• an item is only ever done at the end of that process (e.g. when it is completed, or when we decide we won't fix or implement that thing). Before that, when ones step has been completed, it is waiting for the next step (i.e. To-do, just for someone else)

Bringin all this together: When you have a new item, the work required to move it to the next stage might be to categorize, prioritize or describe the item in more detail. In such a workflow a new item is waiting to be categorized, prioritized or described, it other words, new items are of the category To-do. 

[Wade Tracy _Boise_ ID_]

The problem is some people think differently.  Atlassian is in the category that says done means 'we are done processing this issue' whether the final resolution is resolved* or won't do.  Other people (I'm one of them) don't like the idea of a task being in the done category if the task wasn't worked on at all (resolution = won't do).  An example would be my teenage son saying his chores are done when what he has really decided is that he won't do them.  That wouldn't and doesn't fly with me =)

A better name would have been closed if you really wanted to stick with the 3 category approach, but allowing people to create categories would be better.  Since it can't be changed currently, this just falls under one of those 'oh, this is how I have to think now' situations.  It's a pain, but when I report, I look for things in the done category and then I have to break those issues into resolutions--resolved vs not resolved.

* we changed our done resolution to resolved to avoid confusion with the done status category.  Of course now we have a problem with resolved also being the the date a resolution was set =)

[Lance L. Summy]

Recommend revisiting the link provided in the 2018 comment above.  https://jira.atlassian.com/browse/JRASERVER-36241

It appears that Jira Status "Categories" is not suited for your expectations or usage.

Recommend creative use of workflows and statuses in conjunction with unique resolutions. 

Another option is to create a custom field and script your own "Category" to display expected results.

Other options discussed in the link above may also achieve the results you are looking for.

Either case, it appears that Atlassian made their decision and are not adding additional status categories at this time.

[Manh Auze]

Manh cer admin