How to simplify and improve your Jira workflows

Matthew Flaws | Sat, May 09, 2020 | Atlassian Products | Guides | 0 comments

Since May last year, the team at New Verve have been looking introspectively to identify and reinforce any potential improvement areas.

One such area was our Jira workflows; increasing growth, and less maintenance than what we would like, had resulted in outdated and cluttered workflows.

For example, why configure and maintain 28 workflows (not counting the extra 17 inactive workflows), utilising over 70 combined statuses (seriously), when five workflows sharing eight statuses will do?

Complexity provides excess and unnecessary stress. Simplicity is the key.

But how do we separate and remove what is unnecessary and leave only the purest of essentials? First we must understand what is necessary.

Understanding Workflows & Statuses

If we think about the most basic workflow, any work item must ALWAYS be in one of three states:

• To Do - The work item has been created, but is waiting to be actioned by the relevant team member.
• In Progress - When the work item has been started by the relevant resource, it is now In Progress as it is in the process towards completion, but it is not yet complete.
• Done - Once the work has been completed by the relevant team member, and no more work is needed, it can then be classified as Done.

There is no other state a piece of work can be in, with each state flowing in order from ‘To Do’ → ‘In Progress’ → ‘Done’.

We can use these three work states as a foundation to expand (if needed) to fulfil our workflow needs:

While each workflow may require a handful of bespoke statuses, they can all be derived from either To Do, In Progress, or Done (although I am of the opinion that there can only be one form of ‘Done’, which I can explain in another blog post). Fortunately the three main states nicely coincide with the ‘Status Categories’ found within Jira.

There are a few rules of thumb that I tend to follow to gain a better understanding of how to derive my needed statuses:

• The first status an issue is created in will most certainly be a ‘To Do’ category status, as it is nigh impossible for issues to be actioned as soon as they are spawned.
• As soon as work has started on an issue, it is constantly and forever ‘In Progress’ until it is complete.
• Complete, or our definition of Done, means that there is no more work to be done on that issue and is ready for sign-off by our client which will be the last status in the workflow (However, YMMV).
• There should ideally only be a single ‘Done’ status, as how can an issue be both ‘Done’ and not actually ‘Done’ at the same time? (Schrödinger’s Issue?)
• If an issue is not yet ‘Done’, and it is no longer in a waiting queue to be completed, it is ‘In Progress’.

For example, if your issues start in a status named ‘Product Backlog’, this status must be derived from ‘To Do’ as the issue will be waiting before it can be actioned. The same could be said if the issue transitioned from ‘Product Backlog’ to ‘Sprint backlog’. The issues would not yet be actioned, so ‘Sprint Backlog’ would also be a ‘To Do’ status. However, if the next status of the work requires users to contribute work to the issue, the next status would be an ‘In Progress’ category status.

Let’s pretend that there is only one ‘In Progress status where all the work is done, and then once the work is complete, the issue can move to the next status. The next status should be a ‘Done’ category status. With this formula you can create a workflow consisting of 3 minimum steps (which may be acceptable, or too lean), or of 30 steps (which may also be acceptable, in the right context, or could be overly complex).

However, how do we know which steps we absolutely need for our workflow? For this we need to understand our work items that we will move towards completion and identify the work streams where our work comes from.

Identifying Main Work Streams

To give some context, we are a growing consultancy business providing three main sources of service:

1. Client Projects - Delivering solutions to clients based on project requirements
2. Product Services - Development of New Verve’s Jira applications for the Atlassian Marketplace
3. Maintenance & Support - Providing maintenance for the Atlassian applications hosted by New Verve on the behalf of our clients, and support for any issues experienced with Atlassian applications

Each project solution we provide contains work items, or issues, that flow through the exact same steps towards completion.

For example, each project that represents one of our client projects has the same actions we need to perform:

1. Create the issues/work items based on requirements in a backlog,
2. Order issues in terms of customer priority,
3. Mark issues ready to be developed,
4. Work on issues,
5. Wait for review,
6. Internally review issues,
7. Wait for deployment (if issue is script related),
8. Deploy (if issue is script related),
9. Mark an issue complete from our end,
10. Wait for Sign-off of completed issues with the relevant client,
11. Mark the issue as closed

These steps need to be followed for each client, whether we have one or 100 clients. Each project solution, or work stream may be different, requiring more or fewer steps to complete the work. For this example, I’ll stick with the Client Projects work stream.

Translating Work Steps into Statuses

When looking at the steps needed for each work stream, it may seem logical to create a status for each step without thinking about how the user is to use the workflow. Using the Client Projects example above I could easily create 11 statuses, one for each step, but why? Do we need 11 statuses? (Spoiler: The answer is ‘definitely not’)!

Looking at a comparison of the two flows above, the bottom flow looks quite excessive. We can whittle down the needed statuses by asking ourselves if we really need it to function.

Obviously we need a ‘Backlog’, otherwise we wouldn’t have a place to create issues for the client project. However, do we need another status to mark that the issues need to be ordered, or is there another way to show this?

I would say ‘no’, we don’t need another status, and there is another native way to show ordering of issues within Jira, namely the ‘Rank’ of the issues. So we can scratch that status.

Next would be ‘Ready for Development’. What is this status for? What does it represent? Why do we need it?

This status is to make sure that all Jira users know that is issue is ready to be completed, or in other words, it is to be done (i.e. To Do).

Another rule of thumb I like to follow when naming workflow statuses is to have them as succinct as possible without losing their meaning

Having ‘To Do’ instead of ‘Ready for Development’ reduces mental burden, takes less space, and still conveys the same message.

Additionally, I like to have my statuses in such a way that they can be inserted in to the sentence ‘This issue is _____.’, where the blank can be filled in by ‘To Do’, ‘In Progress’, or ‘In Review’.

Once again this is mainly for ease of communication.

‘Work on issues’ is definitely needed, as this would show that it is actively being worked on by somebody and is not longer waiting. This could easily be replaced by ‘In Progress’ to keep it simple and to follow the rule of thumb above.

The following status would be ‘Waiting for Review’, a place to move the issue to when development has stopped but hasn’t been picked up again for review. Is this needed? Is there another way to show this? I’d argue that we don’t need any ‘Waiting for x’ queues, due to the fact that all it serves is another place to put things without actually producing any benefit. What would be the difference if instead we placed the issue into a single ‘Review’ column? Couldn’t we know that the issue needs to be reviewed by the fact it is in a review column, and the fact it hasn’t been moved out of the column would signify that it hasn’t been reviewed?

That bears the question of ‘How do we know if the issue is currently being reviewed or not?’, which can simply be answered by if the issue has an assignee or not. If there is a user assigned to an issue in the review column, then it is up to that user to review and move the issue further towards completion. This means that instead of having ‘Awaiting Review’ and ‘Internal Review’, we can have a single status of ‘In Review’ (or even ‘Review’ if you wish to cut all unessential verbiage).

A good rule of thumb to think about statuses is if the work is being passed from one person to another, to include additional value such as a review, then a new status should be used to signify the exchange.

In this example we are moving from ‘in progress’ to ‘In Review’ to signify that another user will be reviewing the work done by the first user.

However, if we wished, we could have a single ‘In Progress’ status for both the work and the review, although we would be losing some crucial information, namely signalling to other users that the work needs to be reviewed.

After being reviewed, if the issue is an automation script to be deployed on a client’s Jira instance, it would need to be marked ‘ready for deployment’. But why? Does it need to be marked as ready for deployment, or even marked as having been deployed? I’d say no. Why can’t the reviewer deploy the script if the changes are satisfactory? And if the issue is to be marked as having been deployed, that means that it is ready to be demonstrated to the client for issue sign-off.

So really, why can’t the reviewer deploy the script if the script is acceptable, then mark the issue as complete? In our example, they can, why not!

The other action is if the script is not acceptable, in which case it would need to be assigned back to the original user assigned to the issue and moved back to ‘In Progress’. By now the Issue has been created, ranked, processed, reviewed, and is now marked as complete (meaning New Verve has completed its job in providing the output). All we need to do now is wait for sign-off by the client to confirm that we have indeed created what they desired. But do we need a waiting status for that, if every issue in ‘Completed’ need to be signed off as soon as it is in that status? No. We don’t.

The same could be said for ‘Mark as closed’. Is there a need to have a status to mark the issue as signed off once we get the green light? Possibly, but is there not another, more effective, and much more elegant way to mark the issues?

Yes, there is, Resolutions, and it is a System Field too; no custom field overhead!

So if the issue was moved to ‘Completed’ to signify that the issue was done by New Verve and requires signing by the client, and once we receive the sign-off, we can set the resolution field to equal ‘Done’ (or any other resolution name of your choice. I like Done because it is default and means I don’t have to manually add another resolution).

If we put this all together we get:

From 11 steps down to 5 statuses (Easy-peasy, lemon squeezy)! Much less potential confusion of ‘where’ an issue should be, as more statuses usually means more transitions (Tired, stressed, lemon zest).

A final rule of thumb would be that a workflow should ideally have seven statuses or less.

Only in highly specialised cases would there be a need for more than seven.

Hopefully you found this article useful. Now you can take this knowledge away and potentially improve your team’s workflows and get a nice (rule of) thumbs up!

Related Reading

If you enjoyed this blog, you may like Tips and Tricks for Successful Jira Project Management.