How to set up a good Jira workflow

Jira workflow design: The entire process at a glance

Workflow design is basically the visual organization of statuses. This results in a diagram of a specific workflow that maps individually created statuses. Statuses are linked by transitions, which define the process of an issue. Different status categories, like TO DO, IN PROGRESS,  or DONE, are colored differently. This makes it easy to assign individual statuses to the relevant categories, providing more clarity in the workflow design, which contributes to improved readability. It also leads to a better understanding of how processes work and increases the acceptance of the workflow for users as well as administrators.

Due to my professional background as a process manager, I pay special attention to easy-to-read workflows. There are three variants of visualization to make a workflow more readable, which we will explore below.

Event-driven process chain (EPC)

Of course, we do not build event-driven process chains in Jira, but this type of visualization is one of the most frequently used.

The ideal flow of the process is charted from top to bottom. Important statuses or ones that deviate are placed to the left or right of the process flow.

Business Process Modeling Notation (BPMN)

In this version we build processes similar to the EPK diagrams, but these are read from left to right. In my opinion, they provide understanding because they are easier to transfer to Kanban or Scrum boards (practically as well as mentally).

Waterfall model

With the waterfall model, we organize statuses in a stepwise order. We start at the top left and work downwards to the bottom right. This form of representation has a special advantage as transitions can be separated optically, and return-flows can be made so that they are clearly recognizable.

It can be seen as a hybrid of both diagrams mentioned above because it combines the advantages of the event-driven process chain and BPMN diagrams in terms of readability, especially for more complex workflows.

This applies to all three variants: Cross transitions must always be avoided.

Workflow and business rules

I would like to emphasize that I'm not interested in imposing rules. Rather, I see the point in clearly defined conditions that guide every user and administrator.

Disclaimer: This paragraph is the most controversial point in the whole Atlassian community. I look forward to your feedback and invitations to conferences and podcasts!

Status names: Simple, global, reusable

An essential factor for a good Jira workflow is the optimal naming of the individual statuses. But how do you find the right names? It helps to remember the aim—to describe the state (not status) of an issue. And it should be as simple and abstract as possible.

Status naming is a frequent point of discussion among companies and communities. Here are a few tips to bring a clear and understandable structure to status naming:

Statuses, consisting of one word, such as Open, Closed, or Waiting, describe issues in which no one is working. Statuses with one or more persons actively working are called IN Progress, Review, or Test.

Another important point in the naming of statuses is reusability. Statuses may and should be individual, without defining a status in an overly detailed way, think, "as much as necessary, as little as possible."

All projects with different test phases are In Testing. This status does not explain which test is meant, whether E2E (End-to-End) or UAT (User Acceptance Test). And it is not necessarily important to know especially when more than one type of testing takes place. The important thing is that the global assignment works for all operations and that the status is defined.

Furthermore, the same or similar statuses in different categories should be avoided. This provides structure and helps to move an issue consciously to the next status. To support the directed workflow of an issue, it is important to assign it to the appropriate categories.

As soon as a status is reached that belongs to the status category In Progress, all further statuses must also belong to it. It is important to distinguish between actions that can be influenced and those that cannot.

If you are waiting a long time for an external service provider, you should ask yourself, "Can I still influence this myself or do I close the ticket?" A conscious decision must then be made here.

Status rules: When do I need a status?

When do I need a (new) status? Have you ever asked yourself this question? Maybe in meetings where the business department asks for one status after the other? Have you also wished you had an argument for and against? Many years ago, I asked myself these very questions too; I researched and talked about them with different people and read articles, and the following list of questions resulted:

1. Do people need to receive a message?
2. Are only certain people allowed to make a transition to a status?
3. Does the responsibility change from the previous to the new status?
4. Must people be able to filter this status?
5. Must people report this status, e.g., time in status?

If all of these questions can be answered with a YES, waiting queues (warehouses) are another topic that needs to be considered separately.

Waiting queues

For me, waiting queues are preliminary statuses where no work is being done. This is where the process lies and waits to be dragged into the corresponding subsequent status. One of the reasons these statuses are used, in my opinion, belongs to a bad workflow design (often the push and pull principle).

Let's take a look at the following example:

In this workflow, there is a preliminary status. This is to indicate that an issue is available for the next work step.

If we remove these statuses and extend the workflow with a post function that ensures the assignee is reset in a status transition, e.g. from In progress to In review , we have the same result.

Accordingly, the Kanban Board column shows assigned and unassigned issues. An employee can therefore ACTIVELY TAKE an issue (PULL). Here we save at least three statuses.

Tip: Try to avoid waiting queues and use workflow functionalities to keep the push and pull principle.

Start and end status

In my opinion, there is no good reason that workflows in an enterprise should have different start and end statuses. To keep it simple, the rule is that each workflow starts with the status Open and ends with the status Closed.

This simple rule provides clarity for administrators as well as users who want new workflows or are allowed to work with existing ones.

Status versus solution

Another challenge is the mixing of statuses and resolutions. As mentioned, the last status should always be Closed. A status like Done, Deprecated, or Withdrawn does not exist because it is not a status but rather information, i.e., the solution.

Tip: Ensure that during the closure operation, the corresponding information (solution) is set.

Transitions vs. information

A transition must exist for an issue to move between two statuses. A transition is a one-way connection, so if an issue needs to move back and forth between two statuses, two transitions must be created.

In software development teams, you notice that there are statuses: Prioritization, preparation, and refinement. These may be necessary and reasonable in larger organizations or planning boards. But you should ask yourself what really happens in these statuses.

Often in team meetings, we fill out fields like Priority or Story points at the end. There are much easier and nicer solutions, for example using sprints or apps like Structure. Statuses like the ones mentioned above lead to increased workflow complexity and provide less benefit to the team than to the product or project manager.

All Transitions

I am deeply divided about the so-called All Transitions. A process is a directed flow of actions, but All Transitions allow issues to be moved back and forth between statuses. For example, issues can be moved from several statuses to On Hold. In this case a directed process is no longer guaranteed. It is even more important that every status change is a conscious decision.

Because a transition explicitly or implicitly adds more information to an issue, it is different from the other in previous statuses. All Transitions can therefore cause confusion if issues are moved too quickly and carelessly. I would argue to a certain extent, that they discourage discipline. Used well and handled consciously, they can accelerate and simplify a workflow.

There are many points that make up a good Jira workflow

An easily readable workflow design with different status colors and clearly structured transitions form the basis. In addition, general workflow and business rules for status names and the clear definition of start and end statuses improve the workflow as well.

The fact that every status change should be a conscious decision helps to adhere to defined status rules. In this way, waiting queues can be avoided and All Transitions used in a targeted way. The aim should always be a directed process.

I'd like to finish by emphasizing again that there are many ways to implement a good Jira workflow. That's why this article is not about setting and imposing rules, but the possibilities.