Understanding Jira Statuses

[#1]

Jira’s power and flexibility stem from the ability to create workflows for any process. Understanding Jira work item 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 Jira 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. In fact, Jira administrators can create their own statuses (see section below), making the possibilities are infinite. Some Jira 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 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 project/space 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 Jira statuses should be, a good place to start is by looking at the workflows come with Jira project 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 been started, but not yet completed

• Done – Shown in green and representing items 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 Jiar statuses at once.

For example, the Clockwork for Jira time tracking app (I am with the Clockwork team) can be configured to automatically track time when an assigned work items is in an active (In Progress) status.

JQL includes statusCategory() and statusCategoryChangedDate() functions. Along with being useful for search, you can use these JQL expressions in Jira automation conditions to easily restrict an action to work items 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.

There are plenty of options to ensure that a series of specific steps are carried out without creating a workflow status for each step. You can use a bullet list or action items in the work item description, or for more functionality, try adding a checklist (note that I am with the team from Checklists for Jira) to the work item. Checklists have an advantage in that they are compatible Jira automation, allowing you to change/update the list for each status in your workflow.

Jira Status Naming Conventions

Pay attention to how you name your statuses. 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/spaces (not be too specific)

Consider this ITSM Change Management Workflow:

• 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 a work 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 in that status. Avoid using past tense verbs as a status names. 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 item is is approved it then 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 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 Jira statuses, create an automation rule to remind the assignee to periodically check in on, and close out the work items.

A Few Words on "Done" Statuses

In the category descriptions above, “Done” statuses are described as work 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 a 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 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 Jira 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 work item was closed.

As an alternative, you can use automation or a post function to automatically set the resolution when an 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.

Adding, Editing and Deleting Jira Statuses

The workflow editor (Jira Settings > Work items> Workflows) allows you to easily add, edit or delete statuses on draft workflows. If you’re modifying an active workflow, you’ll be prompted to make a copy and do your editing there. Remember to click Update workflow when you’re done.

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, easy-to-use Jira workflows, see this article Status, Subtask or Checklist: How to Divide Work in Jira?