Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How can I create a status category?

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

10 answers

1 accepted

0 votes
Answer accepted

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)

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

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.

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.  

Like # people like this

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

Like # people like this

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

Like # people like this

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.

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

Here here. This pretty much sums my thoughts up.

Like # people like this

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.

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 solvedDecided 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

Like # people like this

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

Like # people like this

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

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

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

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

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. 

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.

Like # people like this

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.

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

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?

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

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

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.

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

Manh cer admin

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"

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

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.

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.

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.

Like JaxCavalera likes this

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. 

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

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you