Agile Flow Metrics — Cycle Time & Aging WiP (Work in Progress)
Continuous improvement is a conscious and deliberate decision to continuously invest and focus on getting better. But how do we know what is our current state and if actions we are taking are moving us to a better place? Quoting Peter Drucker:
If you cannot measure it, you cannot improve it.
In this post, we will share how you can start, with two fields only and spreadsheet tool, extracting efficiency metrics that will help your team to understand what your current state is and follow up the impact of your improvements in the efficiency of the team.
The two fields you need to extract from your issue types are start date and end date. This data is easily available in most of the tools like Jira, Trello and equivalents or you can even track this in a spreadsheet. We are talking about work and this data can be extracted regardless of the method you use, e.g., Scrum, Kanban, Waterfall etc.
In hold of this data, you can calculate a metric called Cycle Time by subtracting the Start Date from the End Date and summing up 1: End — Start + 1. You may be wondering why do we add 1? If a demand arrived and it was finished within the same day, we count every day in which the demand was worked as part of the total. In other words, there will not be any case where cycle time is zero.
Cycle Time is the amount of elapse time that it takes for work to complete (Daniel Vacanti)
Having the cycle time of the delivered demands so far, we are tempted to calculate what the average that a demand takes to be delivered is, correct? Well, we should avoid this. Averages are dangerous, they can hide relevant information. As very well stated:
“If Elon Musk walks into a bar and suddenly everyone inside becomes millionaire, on average.”
Outliers may cause distortion of your average data. As an alternative, we will calculate percentiles. In our example, we are using 50th, 85th and 95th.
What do the percentiles tell us? For instance, the 50th percentile means that 50% of the demands were delivered in 3 days or less. We follow the same rationale for the other percentiles, 85th percentile means that 85% of time this team delivered demands in 9 days of less and 95% in 17 days or less.
If you need to provide a forecast of a single item, you already have a good hint here, you just need to choose what level of confidence to use. The 85th percentile is usually a good level of confidence to use for forecasting work. Feel free to choose the percentile you will use based on how much risk you are willing to take on.
Now we can create a scatterplot chart to visualize the cycle time distribution using End Date, Cycle Time and 50th, 85th, 95th percentiles.
Your policies shape your data and your data shape your policies — Daniel Vacanti.
Interpreting your Cycle Time Scatterplot will help you to find proper levers that will cause a bigger impact in your context. In the example above, we have a triangle-shaped pattern. According to Daniel Vacanti on this book Actionable Agile Metrics for Predictability, this may be caused by one of two factors:
- Arrivals exceed departures: e.g., a project that starts from zero WIP (Work in Progress) or;
- Flow Debt: poor flow policies.
Other patterns may be triangle that fattens out, cluster of dots, gaps, high variability, or extreme outlines. For all of them, we can take actions to improve the flow of work.
Since cycle time is a lagging indicator, the metric will be available once it has already happened. However, we can take leading actions to influence the future cycle time of the work in progress. How? Managing the aging of work in your system. In other words, how many days a work has already spent in To Do or In Progress. We calculate it by taking today, subtracting the start date, and summing up one (we count every day in which the demand was worked as part of the total). In our example, today is 17th Feb.
Another scatterplot chart can be created using only the column Aging from the table above and it will look like below:
The Aging and percentiles help us to manage the work to reduce its cycle time. Every time a work in progress exceeds a percentile, the cycle time of that percentile will increase. The opposite is also true. If we can manage work to be completed under the aimed percentile, our cycle time will reduce.
Armed with this first set of metrics, you can start looking how to improve your flow policies to reduce your cycle time. Also, you can provide a forecast of when a single item will be possible delivered based on data and level of confidence (percentiles) and not on a “guestimation”.
Tip for Scrum teams, if your 85th or 90th percentile indicates more days than your Sprint length is, Sprint Goals are in danger. The time that the work usually takes to be delivered surpass the time you have within a Sprint.
One final recommendation: Metrics shape behaviours … for good or bad. Be careful how to introduce and use metrics with teams, metrics should help to drive improvements, not to be used to beat people and teams.
The happy story is that this is not the only metric you can extract using start and end dates. Let see what else can we generate using only start and end dates in the next post.
References
Actionable Agile Metrics for Predictability: An Introduction Aug 15, 2015, by Daniel Vacanti
When Will It Be Done? Lean-Agile Forecasting to Answer Your Customers’ Most Important Question Feb 16, 2020, by Daniel Vacanti
