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 the 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. This provides more clarity in the workflow design and contributes to improved readability. On the one hand, this leads to a better understanding of how the processes work. On the other hand, it increases acceptance of the workflow – for users as well as for 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:
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 ones.
The “ideal flow” of the process is charted from top to bottom. Important statuses or statuses 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 rather 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 the 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: transitions can be separated optically and return-flows can be made more clearly recognizable.
It can be seen as a hybrid of both diagrams mentioned above, because it combines the advantages of event-driven process chain and BPMN diagrams in terms of readability, especially for more complex workflows.
Applies to all three variants: cross transitions have always to be avoided.
Workflow and business rules
In my view it’s a must for improving and simplifying teamwork: The definition of enterprise-wide rules for the use of workflows and the configuration elements they contain. 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 definitely the most controversial point in the whole Atlassian community, I look forward to your feedback and to 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 what the aim of a status should be: It should 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 in 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, Waiting, describe issues in which no one is working. Statuses in which one or more persons are actively working on are called IN … Progress, Review, Test.
Another important point in the naming of statuses is their reusability. Statuses may and should be individual, but should not define a status in a too detailed way. According to the motto: As much as necessary, as little as possible.
For example, all projects that have reached different test phases are In Testing. This status does not explain which test is meant – whether E2E (End-toEnd) 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 status categories should be avoided. This provides structure and helps to move a issue consciously to the next status. To support the directed workflow of an issue, it is important to assign it to appropriate categories. As soon as a status is reached that belongs to the status category In Progress, all further statuses must also belong to this category as well. It is important to distinguish between actions that can be influenced and those that cannot.
For example: 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 questions as well, researched and talked about them with different people and read articles. One blog post I found at that time I would like to mention here in particular:
Jira Workflows: Best Practices und typical mistakes.
For me, the following list of questions resulted, which helps me with my argumentation. At the same time, it supports the respective team’s or person’s understanding of what a status is needed for and prevents thereby possible over-engineering:
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, the new status is probably useful. Another topic are waiting queues (warehouses). They have to be considered separately again.
Waiting queues
For me, waiting queues are preliminary statuses in which 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 why these statuses are used – but from my point of view belong to a bad workflow design – is the often quoted push & pull principle.
Let’s take a look at the following example:
In this workflow, there is a “preliminary status” (For … Status) before each In … 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 postfunction that ensures that 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.
Try to avoid waiting queues and use workflow functionalities to keep the push & 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 more clarity and understanding – for administrators as well as for employees who want new workflows or are allowed to work with the workflows.
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, Withdrawn, do not exist, because it is not a status but rather information, i.e. the solution.
So make sure that during the closure operation the corresponding information (solution) is set.
The status is the state of an issue. The solution is the information in the status Closed.
Transitions versus information
Info
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 like prioritization, preparation, refinement. These may truly be necessary and reasonable in larger organizations or planning boards. But you should ask yourself the question: What really happens in these statuses? Often these are team meetings where we fillout 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, unnecessarily 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 to move issues between different statuses (back and forth). 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. In this way, it is different from the other in previous statuses. All Transitions can therefore cause confusion, if issues are moved too quickly and carelessly. I argue: to a certain extent, they encourage undisciplined behavior. Anyway: Used well and handled consciously, they can accelerate and simplify a Workflow.
Summary
There are many points that make up a good Jira workflow. An easily readable workflow design with different status colours and clearly structured transitions forms 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 can be used in a targeted way – for example, for on-hold statuses. Overall, the aim should always be a directed process. What I want to emphasize once again: there are many ways to implement a good Jira workflow.
That’s why my blog article is not about setting and imposing rules. Rather, I want to point out possibilities and offer impulses for thoughts. I think it is important that an understanding of business processes exists in an organization and across teams, on the basis of which one can exchange ideas. There are a few best practices that make work easier, especially for less technically experienced employees.
Do you have any questions or would you like to learn more about Jira workflows? Just contact us — we're happy to help you.
