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 stira’s power and flexibility stem from the ability to create workflows for any process. Understanding Jira statuses, the building blocks of those workflows, will allow you to create efficient, easy-to-use systems for delivering work.
What is a Jira Status?
A Jira status is a station on your workflow; a step that a work item goes through on its way to DONE. A status is the answer when a boss or teammate asks, “Where are we at with that?”
A status is one of the two basic elements of a Jira workflow, the other being a transitions, which are used to move work items from one statuses to another.
Example Jira 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 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.
Statuses can typically differ across project/space types.
For example, software projects/spaces tend to have statuses like:
- SELECTED FOR DEVELOPMENT
- IN PROGRESS
- IN REVIEW
- DONE
Jira Service Management projects/spaces usually include statuses like:
- WAITING FOR SUPPORT
- WAITING FOR CUSTOMER
- ESCALATED
And an ITSM projects/spaces 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/space templates.
Jira 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 yet 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 statuses 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 Marketplace apps allow you to use a status category as shorthand for referring to multiple statuses at once.
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 Statuses 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.
Jira Status Naming Conventions
Pay attention to how you name your statuses. Jira 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 work item 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 item 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 statuses are written as gerunds, -ing verbs. They tell us exactly what is happening with the work items. Avoid using a past tense verb as a status name. A status called REVIEWED does not tell the user what is happening with the item, 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 item is approved in moves on to the next level of approval in the workflow 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 the status to be used in other types of projects/spaces. A business project or HR project may use the IMPLEMENTING status in a 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 items 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 work items accumulate and are ignored. If you use these type of statuses, create an automation rule to remind the assignee to periodically check in on them, and eventually resolve them.
To Find Your Current Jira Statuses
Before you create a new Jira status it’s good practice to check if the status you need is already available in your Jira instance. Jira is designed so the same elements, including statuses, can be shared by multiple company-managed projects.
To find your currently existing Jira statuses, login as an administrator and go to Jira Settings > Work items> Statuses. You can see a list of all statuses, the status category and the associated workflows. You can also add statuses here to make them available when creating future workflows.
Adding, Editing or Deleting a Jira Issue Status
The workflow editor (Jira Settings > Work items > 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/spaces 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.
A Few Words on “Done” Jira Statuses
In the category descriptions above, “Done” statuses are described as items which no longer need to be worked on, rather than as items 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 another work item 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 information without complicating your Jira workflows:
- A Done-category status, is just that, a status. It is the a step (typically the last one) an item goes through 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 work item was marked as done.
Jira comes with some default Resolutions, but administrators can add more by navigating to Jira settings > Work items > Resolutions.
The Resolution field on each work item 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 item was closed.
As an alternative, you can use automation or a post function to automatically set the resolution when a work item is transitioned to a done-category status.
Note that if you’re workflow allows items to be reopened, you’ll want to include automation or a post function to clear the Resolution field when the item 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.
For more information about creating simple, easy-to-use Jira workflows, see our blog Status, Subtask or Checklist: How to Divide Work in Jira?
