Dave, this should be reconsidered. We have many tickets that are 'invalid,' and right now they are being tagged as 'done', which is extremely counterproductive. We should at least be able to add one custom category. 

It could be very useful to have another workflow category for status In test/In Review so we can see in recap progress bar of release page 4 colors:

Grey as to do

Blu as in progress

"new color" as in test/review

maintaining a standard approach of Atlassian

Adding more custom status categories may not be a good fix as it might affect the internal implementation of Jira features. But can we have custom groups or any other way to categorize the statuses? Since we have the option to build our own workflows with the custom status we can not put all these statuses into these 3 categories. When we make filters, status categories are becoming useless and it is very difficult to manage all the filters by adding or excluding individual statuses.

Totally agree with David. 

Dave you should consider it again - adding it helps build more effective JQLs using StatusCategory instead of Statues which helps build multi-project boards and dashboards. If needed, happy to provide you with detailed cases.

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. 

This is very silly. It should be an out-of-the-box feature. 

You could all save yourself some time if you realized that Atlassian knows what is best for you. Quit trying to make your own workflow to support your business and only do it the way they say it should be done. That is why we pay them higher licensing fees each year for less and less features out of the box.

This should definitely not be "Closed" and ignored.  It really limits the usefulness of Jira and it's not something we as administrators can easily edit, because believe me, we would take it into our own hands.

@DaveMeyer

This would be a very useful feature. Especially thinking about "Failed" / "Rejected" / "On Hold" etc. which is none of the predefined status categories. It's not open anymore, nothing in progress and definitely not done!

So why Atlassian is so balky about this issue? I really do not understand because it would bring so much benefit to so many users.

For those adventurous enough, the code is in
jira-project/jira-components/jira-core/src/main/java/com/atlassian/jira/issue/status/category/StatusCategoryImpl.java

I was able to recompile a copy of this file using install.dir/external-source/build.xml and Ant in Jira 8.5.3
I had to download jsr305-3.0.2.jar to get it to compile.
That's one way to change colors but you are restricted to the ones already defined in
issue-status-plugin-2.0.2.jar

But from the source code I see the cautious comment:

        *
          Status Category Name is hardcoded here instead of taking from default i18n bundle because changing it would
          break existing JQL filters and requires an upgrade task and/or backward compatibility coded into
          StatusCategoryValidator and StatusCategoryClauseQueryFactory.
         */

This is downright shameful. It was bad enough when Atlassian ignored key features that thousands of users were begging for - now they are REMOVING features because they believe we don't need them. Of course, the Add-On vultures are happy to swoop in and provide this feature for an additional per/user cost. I believe Atlassian's days are numbered.

>Resolved 14/Jan/2015

>Still getting comments in late 2019, now early 2020

Atlassian, you need to rethink this. You have plenty of other adjustable knobs(Custom fields, anyone?) you give us and disable us from modifying the ones that you set into the system(Assignee? Epic Name? I could go on).

Let this be another one, clearly this is a desired feature.

+1 - I am used to seeing yellow as an in Test or Review indicator, I think Jira server 7.x.  But now that I am using Cloud, all I see is blue.  It is not helpful.  @Dave Meyer, please consider widening JIRA's color palette.  It's really impactful on communications to enable color usage.

Atlassian wants customers to use Jira and Confluence?  That sounds great.  I'd like a Lexus in my driveway and not have to work for a living, but the reality is money is a factor.  Using Confluence means having to buy a whole new application license.

Atlassian wants customers to use Jira and Confluence but the fact that Confluence has more Status color options is an imbalance that is impacting the user of the tools together. I have a client who is not happy that I cannot show a red status for data I pull from Jira into a Confluence page because it (red) does not appear in JIRA. This is a serious issue that has impact more than one client

Especially since clients do not want to buy another add on..

Yet another example of Jira not listening to 200+ admins..  You've lost my endorsement.  I never thought I'd say that about Jira.  Every time I look for something I need the response is "Try this workaround, won't fix, or some other garbage explanation as to why you won't do the work.  Whoever is designing your new UI is killing your previously loyal customer base.  And there are only 204 upvotes because you're blocking people from upvoting now that you've closed it.

My need : The mapping of blue, yellow, orange and green to "To Do", "In Progress", "Ready for QA" and "Done" 

For development teams, it helps to have a way of grouping some statuses into buckets that represent Development, Validation, User Acceptance, etc.  Having all these as In Progress makes it hard for us to get good info out.

I didn't like this new Jira UI experience, I need more color in the status 

There is one additional valid reason to ask for a single new category. If I want to measure flow efficiency (how much of the total duration of a piece of work has been spent queuing versus working) then I need to have workflow states marked as inactive/waiting/queueing (whatever word most makes sense). Right now, I recommend that people use "To Do" to represent all the waiting. However, I don't know what other metric/visualization that will mess up if that is meant to show the wait BEFORE the work has ever "started". Does this make sense? Can you please tell me what the consequences would be or if a new status would really be warranted?

could you reopen this issue?

the status categories still need.

that issue was not resolved

I just got the new JIRA update.  Among other things, you changed the "visual system", from the status colors from blue, yellow, green to gray, blue, green which seems like a step backwards.  The gadgets were not updated to match.  And the epics colors have radically changed, but the epic color picker are the old colors, so that is a bit odd.  Any way to override the new default status category colors?

How would you programmatically know, that an issue is done? Issues status can be configured and named in any language, so it has no meaning to software in general. A lot of admin do not properly maintain the workflows and often take over the default settings: the resolution is not always set although an issue is done. Currently, the status category is the only available indicator for issues being done as the key="done" of a status category is fix and cannot be modified by any user.

Why would I like to know, if an issue is done? Well, to automatically calculate the progress of e.g. a sprint or portfolio, that's important to count the number of story points of issues being done divided by the number of story points of all related issues!

Hi George, thanks for sharing the plugin, just installed it for a test run.

Hi all,

I understand the reasons why Atlassian is reluctant to add more status categories. I also understand though why many users would welcome them.

I would like to recommend the Status Color plugin. It does not add more categories but it eases the pain a bit. It allows to color issues based on their status in filters, dashboards and agile boards. It is free, most of all. Maybe it helps you as it did us.

http://www.lewe.com/jira-statuscolor-plugin/

+1 to Steven's last comment. Even I (years ago) complained about this feature on this very ticket (and still get updates on it to this day) but I definitely see why categories are utilized the way they are now. If you need full resource planning, JIRA isn't going to cover it. The core product is for Project management. You don't need to buy Tempo AND Structure (also ouch that would be a hassle to maintain) as just purchasing Portfolio should complete your requirements for a full resource utilization suite.

Blocked and canceled are not states in a typical lifecycle of a business process.

"This statusCategory feature request itself is so hilarious to me. Every single person here who is asking for a "blocked" or "canceled" category has seemingly zero idea of how business process design works."

A rather arrogant statement. IMO. Does no one else know how to be successful in the workplace?

JIRA is OK, but it seems to be designed by people that refuse to change their thinking (IMO). Things change over time. Technology needs to adapt. JIRA says "JIRA Software lets teams work how they like." If they really did this, some teams would be allowed to add more categories to statuses, since that is how some teams want to operate.

My team would like to work in a certain way. Unfortunately, JIRA doesn't truly allow that.

Yes, Now I need to buy another product Portfolio for JIRA. Wow! 

Whats funny about having different status category? Include one status and will it destroy report ability? 

I have nothing against JIRA. It was not my choice to buy JIRA software it was there before I joined the project. But if I am given a chance Ill change it and am working towards it.

Cheers!

Well now I'm just confused. Your original comment seems out of place. JIRA doesn't offer or advertise 'resource capacity planning' and never has. Atlassian's own offering is that of the Portfolio for JIRA add-on which is intentionally the resource-capacity planning tool. Portfolio for JIRA also offers hierarchy Anything -> Epic -> Story -> Sub-Task. It seems to me that what you really want is JIRA Software + Portfolio for JIRA.

So to me, it seems like you're complaining that you didn't buy the right product. JIRA isn't bait-and-switching you: Buy the tools that give you the capabilities you want. JIRA offers a great product at a great price point, in my opinion.

This statusCategory feature request itself is so hilarious to me. Every single person here who is asking for a "blocked" or "canceled" category has seemingly zero idea of how business process design works. You do not want more statusCategories. Process lifecycle is either not started, actively in progress, or completed in some fashion. You are supposed to use Resolution to stat what happened to an issue, not a status.

Using a Status for every possible reportable condition destroys reportability, makes navigating a workflow difficult and confusing.

@Steven Behnke 

Well I want to keep track of resource capacity every sprint... I would need to add a plugin tempo. 

I need to view structure of issues  Theme>Epics>Features>Userstory>Tasks ... I would need to add a plugin structure

I just want to add category "blocked", guess what there can only be in three categories  "To Do", "In Progress", and "Done". 

I am new to JIRA and after using Rally, I feel JIRA needs a lot of plugins.

vasavi.kakkat, care to add any detail about what "basic features" jira does not include?

I have used Rally extensively. JIRA just does not support basic features and needs lot of plugins. Such a pain!

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

Closed status should have a RED Status Category. If it's closed it means the story/task may not have been done at all (e.g., perhaps there was no need for it).

We definitely need a RED Status Category for BLOCKED in JIRA.

The idea is to mark issue status in red, i.e. new status category of BLOCKED, in case, a prerequisite to work on the issue, is not given.

An example: The infrastructure team is not able to provide a required data base system to me yet, where I can reproduce and fix an application bug. Therefore, it is impossible to me to solve the issue even if I want to. In that case, we need JIRA to show issue status in red, signalizing, something is impeding the progress on that Issue, i.e. special attention is needed.

Please, F1! Solve it! Thank you.

Great.... So it takes all of a week for some frustrated, keen and capable customers to reasonably adequately address an issue that has been open for over two years. Now the issue becomes one of: compatibility with Jira cloud, and long-term support.

Atlassian are not off the hook. They really need to get such functions supported in the core framework. I don't understand why these heavily-requested and obvious features/limitations are not addressed by Atlassian and they rely on their customer base to solve their problems through variously-supported or in some cases paid plugins. Lazy much? If Atlassian are not going to maintain Jira to the required standard, then how about open-sourcing Jira Core and let us all collab on it!

Great job George! Of course, now all that's left for me is to get off my $Unable to render embedded object: File (% and upgrade JIRA to 7 (it's been on my list, but now you've moved it up). Thanks for the amazing turn around time) not found.

Yeah! @George Lewe you rocks!

@David Rhoderick: Ok, you got us hooked. The JIRA 7 version of the JIRA Statuscolor plugin now supports Agile Boards as well. Get it here: http://www.lewe.com/?p=683

@David Rhoderick: We were thinking about extending the JIRA Statuscolor plugin to Agile boards too but we are just too busy right now. But it's on the radar there as a little dot...

The JIRA Statuscolor plugin is free as well and configurable. Since it uses a different approach, you can even combine it with Raul's.
And yes, unfortunately Cloud users cannot install those plugins.

And for those of us on Atlasssian Cloud (Jira Cloud): Boo hoo!

Because is the first version! In the next weeks I will work to configure them! Thankssss!

And free too. raul.pelaez is the hero we need. Curious why the colored statuses plugin is not configurable?

Use my other plugin to colorize your issues in the RapidBoards also more cool things https://marketplace.atlassian.com/plugins/com.rauliki.kanbancombinedWIP.KanbanCombinedWIP/server/overview

Yes thanks a lot, this is fantastic! Great work!

I hate to ask for anything more but I feel it's going to happen anyways: Is there any way to get the colors to show up on an Agile board? At the very least, in a sprint? I tried to add the field to the card layout but it didn't change the background color.

~Dave