nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Accepted answers

Christopher Jaksch_rlcpmf

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)

All comments

Christopher Jaksch_rlcpmf

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)

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.

Marcello Romani_wvmbod

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

Manh Auze

Manh cer admin

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?

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.

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"

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.

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

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.

Mounir Haddouch

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

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.

Michael Holmes_vsnyrv

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

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.

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.

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

mquickenden

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!

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.

unknown

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

Oliver Abt_krd6fp

At the end there are only three kinds of statusses:

To Do
is everything that needs to be worked on
In Progress
is everything what actively is worked on
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.

Phil M_1tqrp5

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).

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.

Graham Twine_f084uw

@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)

Paul Thomson_ohh5sc

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.

Michael Ballenger_ib2gzm

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.

Andrey Ivanov_u1jyqk

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

Seems as an absolute lack of flexibility.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

issue

jira

jira-service-desk

workflow

status

status-category