Jira’s power and flexibility stem from the ability to create workflows for any process. Understanding Jira issue statuses, the building blocks of those workflows, will allow you to create efficient, easy-to-use systems for delivering work.
What is a Jira Issue Status?
A Jira issue status is a station on your workflow; a step that an issue goes through on its way to DONE. A status is the answer when a boss or teammate asks, “Where are we at with that issue?”
A status is one of the two basic elements of a Jira workflow, the other being a transitions, which are used to connect Jira statuses.
Example Jira Issue Statuses
The most common Jira workflow statuses are TO DO, IN PROGRESS and DONE, but of course there are many more. And since Jira administrators can create their own statuses (see below) the possibilities are infinite. Some statuses differ only in name – TO DO is usually the same as OPEN. On the other hand, some workflows have both a RESOLVED and a DONE status which subtly differ from each other.
Tip: Having multiple Done-type statuses can cause confusion. As an alternative, consider only using one Done-category status and forcing users to set a Resolution (see below).
Statuses can typically differ across project types.
For example, software projects tend to have statuses like:
- SELECTED FOR DEVELOPMENT
- IN PROGRESS
- IN REVIEW
- DONE
Jira Service Management projects usually include statuses like:
- WAITING FOR SUPPORT
- WAITING FOR CUSTOMER
- ESCALATED
And an ITSM project may have specific statuses for handling change management:
- PENDING CAB APPROVAL
- PENDING IMPLEMENTATION
If you’re creating a custom workflow and are wondering what your statuses should be, a good place to start is by looking at the workflows come with Jira project templates.
Jira Issue Status Categories
Each Jira status belongs to one of three categories:
- Todo – Shown in grey, and representing work which has not yet started
- In Progress – Shown in blue and representing work which has started, but not uet been completed
- Done – Shown in green and representing issues which no longer need to be worked on
You cannot create new status categories.
If your status are clearly named, and your workflow progresses through a logical series of steps, then one might well ask why status categories are needed. The answer is that JQL, as well as some Jira apps allow you to use a status category as shorthand for referring to multiple statuses at once.
For example, the Clockwork for Jira time tracking app can be configured to automatically track time when an assigned issue is in an active (In Progress) status.
JQL includes statusCategory() and statusCategoryChangedDate() functions. Along with being useful for search, you can use these functions in JQL expressions in Jira automation conditions to easily restrict an action to issues in a subset of statuses.
How Many Jira Issue Status Should a Workflow Have?
So how many statuses do you need? That depends on your workflow. Be warned, however, that too many statuses can make a workflow overly complicated. When deciding whether or not something should be a status, ask yourself if you would ever query or report on that status. If the answer is no, it probably doesn’t need to be a status.
Also, keep in mind that one of the advantages of using Jira is that it makes work visual. Statuses correspond to columns in your Boards.
If you want to ensure that a series of specific steps are carried out, but don’t want to create a status for each one of those steps, consider using a checklist. You can configure checklists to be automatically added to issues of a given type, and can integrate checklists with Jira automation to advance the issue through the workflow as the checklists become complete.
Jira Issue Status Naming Conventions
Pay attention to how you name your statuses. Jira issue status names should:
- Be short and easy
- Tell the reader what’s being done (or what needs to be done)
- Be in the present or gerund tense
- Be usable across multiple projects (not be too specific)
Consider this ITSM Change Management Workflow:
.png)
- The first, to-do type status tells us that this issue type is used for normal or major changes, and that work should not even begin without the first level of approval. Although the name is a bit long, it tells us that an issue in this status is waiting for Change Manager approval.
- Further levels of approval may be required depending on the magnitude of the change. Notice that all of the In Progress (blue) category issues are written as gerunds, -ing verbs. They tell us exactly what is happening with the issue. Avoid using a past tense verb as a status name. A status called REVIEWED does not tell the user what is happening with the issue, or what needs to happen next. Likewise, although this workflow includes multiple levels of approval, there is no status called APPROVED (although that would be a perfectly good name for a transition). If the issue is approved in moves on to the next level of approval or to the IMPLEMENTING status. If it is not approved, it moves to CANCELED.
- Keep status names as generic as possible while still conveying the necessary information. This workflow uses IMPLEMENTING, not IMPLEMENTING IT CHANGE. That allows tthe status to be used in other types of projects. A business project or HR project may use the IMPLEMENTING status in Policy workflow.
- Finally, note that there are three Done (green) category statuses. In this case, Done means the implementation has been completed or canceled. Only the CLOSED status signifies the last step in the workflow, as indicated by the fact that it has no outgoing transitions. The workflow requires the change manager to actively ensure that all issues get closed and do not linger indefinitely in the POST IMPLEMENTATION REVIEW or CANCELED statuses.
“Dead end” statuses like ON HOLD or PARKED can be a useful, but it can also be a place where issues accumulate and are ignored. If you use these type of statuses, create an automation rule to remind the assignee to periodically check them.
A Few Words on “Done” Jira Issue Statuses
In the category descriptions above, “Done” statuses are described as issues which no longer need to be worked on, rather than as issues where the work has been completed. That’s because there are a lot of ways to get to Done. It could be that the work was completed. However, it could also be that the product manager decided that not enough customers would benefit from the feature to make it worth investing the needed development time. Or you might discover that you had already created an issue for the exact same thing.
Do those scenarios sound familiar? They are among the default options available in the Jira Resolution field.
If you find the difference between various “Done” statuses and the Resolution field confusing, you’re not alone. In some ways their uses overlap. However, understanding the difference can allow you to capture important project information without complicating your Jira workflows:
- A Done-category status, is just that, a status. It is a step (typically the last one) an issue makes in your Jira workflow.
- A Resolution is a Jira dropdown field, that includes an associated date/time stamp. It tells you when and why the issue was marked as done.
Jira comes with some default Resolutions, but administrators can add more by navigating to Jira settings > Issues > Resolutions.
The Resolution field on each Jira issue is set to Unresolved by default. To set the field, you can add a transition screen with Resolution field required. This way you always no exactly why the issue was closed.
As an alternative, you can use automation or a post function to automatically set the resolution when the issue is transitioned to a done-category status.
Note that if you’re workflow allows issues to be reopened, you’ll want to include automation or a post function to clear the Resolution field when the issue transitions out of the Done status.
While there are some perfectly functional workflows that have multiple Done-category statuses, using the Resolution field allows you to simplify your workflow and reduce confusion by having only one final status.
Adding, Editing or Deleting a Jira Issue Status
The workflow editor (Jira Settings > Issues > Workflows) allows you to easily add, edit or delete statuses on draft workflows.
Unless you’re just fixing a typo, avoid editing the name of an already existing status. While the workflow editor displays a helpful message telling you how many projects share the workflow, a status in that workflow can be used in other projects without your realizing it. Therefore, changes you make to the status will impact other workflows in other projects.
For more information about creating simple, useable Jira workflows, see our blog Status, Subtask or Checklist: How to Divide Work in Jira?
