Skip to main content

Getting to 85 - Agile Metrics with ActionableAgile Part 3

March 21, 2019

In the first part of Getting to 85 – Agile Metrics with ActionableAgile we looked at the Cycle Time Scatterplot created by ActionableAgile software. That piece also discussed some ideas the scatter plot could bring about and conversations that potentially might occur.

Part 2 took a deep dive into the wonderful world of the Cumulative Flow Diagram (CFD) and discussed the useful information that can be inspected and discussed by the skilled Scrum and Kanban practitioners.

Let’s turn our attention to another kind of a chart – Aging Work in Progress. Unlike both the Cycle Time Scatterplot and the Cumulative Flow Diagram this one takes a much narrow just-in-time snapshot of teams work.

Age is Not Just a Number for Agile Metrics

This is a chart a Scrum Team practicing Kanban should be looking at on a daily basis. And what is a better time to inspect your work than team’s Daily Scrum. What can we glean out of this chart? Quite a lot. In part 1 we talked extensively about Cycle time, percentiles and their importance to the work predictability.

Aging Work in Progress chart

Aging Work in Progress chart gives us a lot of just-in-time data about how predictable our still in-progress items are. The columns of the chart show team’s workflow steps, while the axis Y shows items age in time (usually days). For every column, based on historical data select percentiles are calculated and colored using a specific color scheme.

The coloring is a very powerful tool that gives the data on a chart an instant pop. For example, if a work item is in a yellow zone, it means it passed its 50% estimate (which is in our case for the Dev Done stage was 7 days). An astute Scrum practitioner will immediately recognize red and orange areas as deserving immediate attention and, that’s right, a conversation.

Let's Talk It Through

What kind of a conversation that might be? The Daily Scrum concerns itself with team’s inspecting its progress towards the goal and assessing its capabilities of hitting that target. From the chart our 85% for testing is about 16 days. Looking at items in the Analysis Done stage we notice an item that just hit almost a halfway of 7 days. What can we actually say about that item?

Remember, that 85 percentile means that for every given work item the probability of getting it done in 16 or less days is 85%. On the other hand, there’s a 15% probability that this item will take longer than 16 days to complete. Or in other words out of 100 items about 15 of them are expected to take longer than 16 days.

This means that if an item in progress ages to its 8th day, its probability of NOT begin completed in 16 days doubled already to 30%, thus reducing the probability of successful completion under 16 days decreasing to 70 from 85%. If the item hits 12th day, the chance that it will take longer than 16 days increases to 60%. Do you think that’s a worrying sign? Do you think this item deserves a close attention from the team member? I surely do - these questions are the core to inspecting and adapting your agile metrics.

What About the Bigger Picture of Agile Metrics?

Stepping back from inspecting a single item and looking at the snapshot of your work as a whole might give you some more valuable information. What is our general state of affairs? Do our work items flow on time? Can we make a more educated than our gut feel guess about the state of our progression towards the Sprint Goal based on the picture presented by the Aging Work in Progress chart?

In the case presented above all in-progress items are between 50 and 85% in their respective states. Is that a reason to be alarmed? Those 5 items that just broke into the quite wide band between 85 and 95% - are those a good reason to have a more detailed discussion about? Answers to these and other questions will depend on the context of your work, team and the process. But asking these questions is an integral part of getting your work system to the predictable and stable state.

ActionableAgile software allows user to select which percentiles to show, the color scheme (I prefer the default green-yellow-red very much), and date range to select the data for percentiles calculation. These selections give you a significant variety of ways to represent and highlight your agile metrics.

In the next, and hopefully last part, to wrap up our conversation about Agile Metrics, I will take a look at the Monte Carlo simulation that allows the teams to get better idea about how many items they can complete within a specified time frame. Another Monte Carlo simulation we will touch upon deals with answering the question when a batch of work comprised of multiple work items can be done.


What did you think about this post?