Introduction
Jira workflows guide issues through the various stages of your process, from creation to completion. However, in many organisations, teams can take a casual approach to defining their workflow, losing the opportunity to develop meaningful flow metrics and enhance overall efficiency. In this article, we’ll explore how to enhance your Jira workflows so that you can optimise your software delivery through improved flow metrics.
Simple Workflows
Many Jira workflows consist of simple “ToDo,” “In Progress,” and “Done” lanes. While this setup is valid, it has limitations. There are two key issues with this scenario.
Work Lanes Do Not Reflect Actual Process
Regardless of the work’s different phases (development, code review, testing), teams often use coarse lane definitions such as In Progress to represent items being worked on. We can gather some useful information with this setup but the oversimplification can obscure insights into your delivery process.
The example below, taken from Delivery flow, is based on a simple Jira Workflow supporting 3 Jira statuses – ToDo, In Progress and Done. With this workflow, we can still calculate average cycle time and understand other details such as current work in progress (WIP). However, because we only have a single work lane, there are no insights on process performance within the In Progress step. The clock simply starts once an issue enters In Progress and stops when it leaves. This also results in the 100% flow efficiency calculation. With this workflow, the team achieved flow perfection, a clear indication that something is wrong.
No Waiting Lanes
Work rarely flows seamlessly from one activity to the next. Typically, work completed in work step 1 may have to sit waiting for a resource to become free in work step 2 before work can continue. Introducing waiting lanes (e.g., “Ready for QA”) may seem complex, as it extends the length of your workflow, but it’s essential for understanding waste and inefficiencies in your delivery system.
In the example below, we are using the same data as in Figure 1 above but this time we have three work lanes instead of one. They are In Dev, Code Review and In QA. We have also introduced some waiting lanes, Review Ready and Ready for QA. This team also had the behaviour of placing issues in the On Hold lane when issues encountered a significant blocker. Essentially, this is another waiting lane.
Here, we have the same headline metrics but this time, we have a more detailed breakdown and understanding of where time is being spent once an issue is in progress. In this case, time spent in QA amounts to 30% of overall time. This could be the expected result in your environment but in this case, it was a level of investment that was unexpected prior to the data creating this visibility. An even bigger issue was the 31% of time spent waiting for testing to begin. This is a significant amount of waste that immediately begs the question, how can we reduce this number to 25%, 20%, 15% and so on. These numbers raise big but targeted questions, which are the starting point of a continuous improvement effort. All of these insights were invisible when they were hidden in a single In Progress work lane.
Recommendation: Include all of the work and waiting phases of your process in your workflow.
Updating the Team
When introducing a new workflow, in my experience, you will run into some resistance within the team. This is natural as the new workflow will be more complex than the workflow it is replacing. You are introducing additional process which will require additional discipline from the team. Developers are usually sceptical of additional process and rightly so. That is why you must explain why these changes are necessary.
Communication is critical. I see 4 key points:
- Help the Team Understand: This is not about process for the sake of process. In the same way that we instrument our code so that we can understand performance of our production systems, we are generating data to help us understand and improve our delivery system.
- Data-Driven Approach: We want to shift the mindset from personality-driven, “highest paid person” decisions to data-driven ones. We want to use data as the key input to our continuous improvement cycle.
- Focus on the Work, Not the Worker: Developers can fear how the data will be used. Explain that these changes are focused on improving work processes, not individual performance. Follow-through on that promise.
- Listen to Input: Involve the team in the decision-making process. Their insights are valuable for refining the workflow.
Rolling Out Changes
Once you go live with the adjusted workflow, when calculating cycle times for issues, you need to consider items that were in flow before and after the new workflow was added. Here are some considerations and recommendations.
New Jira Statuses: The new statuses will only apply to issues created after the update. Historical data won’t map accurately to the revised workflow. You need to factor this into your queries and reporting.
Delimiting Data: Use Jira Query Language (JQL) to filter data based on the workflow’s introduction date. For instance, if the new workflow went live on May 1, 2024, use “created >= 2024-05-01” in your queries to ensure you only include issues with the correct status values in your calculations.
Short-Term Issue: Over time, more data will align with the new workflow. In my case, I usually like to go back 3 months when reviewing flow data. In this case, by August, including the date in JQL queries will no longer be necessary.
For input on how to calculate average cycle time in Jira, read this article.
Conclusion
By amending your Jira workflows, you can enhance your flow metrics, gain valuable insights, and drive continuous improvement. Remember: it is about the work, not the worker. Engage your team, embrace data, and watch your processes thrive.