I've been noticing a lot of story point estimation and velocity bashing recently. On the contrary, there is a rise in promoting flow metrics.
I've been using flow metrics for some time too, and in this blog post, I want to share my experience using them.
First, I use them completely abstract from Scrum. I've used them both within and outside of Scrum. So Scrum is not a blocker to using flow metrics. On the contrary, flow metrics show how good your flow is within the Scrum framework and point out some key problems. Scrum Sprints ideally start with "0" WIP and finish with "0" WIP. So this is practically very hard for most teams and items are carried over. A "0" WIP target requires fundamental changes in the organization, and most organizations do not want to change that much. But then, all the handovers and wait times in the value stream reveal themselves as part of flow metrics. For instance, it is not uncommon to see cycle times with an 80% confidence going beyond Sprint lengths.
(I teach scrum.org Professional Scrum with Kanban trainings if you want to learn more about how Kanban and Scrum can be used together)
Here is a real example of an improvement. This chart shows how the cycle time changed every four Sprints for a Scrum Team I coached once
Cycle time scetterplots
This is one of the most useful charts I find.
Help us understand how dispersed our completion time is.
Reveal outliers and patterns.
Shows cycle time within different confidence levels (85% being a popular one).
Helps us set SLEs (service level expectations).
Monte carlo Simulation
I like using Monte Carlo simulation for probabilistic estimating. I use the Actionable Agile tool along with the data I extract from Jira (unfortunately, Jira doesn't provide this by default). The "When and How Many by This Date" features in Actionable Agile are great.
Cumulative Flow Diagram
CFD are great charts to see historical workload on certain states and problems in the flow.
Some of the thing I partciualrly look at :
Arrival departure rate imbalances
Classic CFD patterns (bulging bands, flat areas, disaperaing bands, work piling up in certain states )
Trend in Passive queues
Aprx avarage cycle time, avarage WIP
How avarage WIP in different states change in time
Some tips :
I use flow metrics extensively myself, and here are the things that I pay attention to.
Right sizing is a good approach if you are splitting the work. If you are using these metrics within Scrum framework, the item can be split to fit into a Sprint. Otherwise your SLE can be taken as a reference. For instance if you aim to complete your items within 20 days with 80% confidence, you can refine your work items to fit into 20 days.
I like measuring different cycle times , between different states in our workflow. That allows me to see where the real dispersion is. Sometimes from "Ready" to "Done", "planned/committed" to "Done", "Code review" to "Done". In other words, you can break down your cycle time for more detail analysis.
I like looking at cycle time of different work item types. Once, I found out bugs' cycle time was worse than the overall. That was a very important insight.
Data set is important. You can clean your data before you draw any conclusions . If you have rotten tickets in your data set but somehow managed to close those items, those can inflate your cycle time. You can look at the result with and without such tickets to see if you can see a patterns or a problem.
Someting that worries me:
Flow metrics are calculated using "tickets," and seeing everything from a ticket perspective concerns me. That much measurement and focus on measurement can detach teams from worrying about the value and lead them to focus solely on flow. This may not be the intention, but it is very possible. Goal-based tracking can be a complementary approach.
Can we have a balance ? Food for thought.
Sometimes, goal-based thinking, not worrying much about the cycle times, taking time to digest things, and focusing on the learning/discovery aspect of things can be more important and rewarding for the organization.
Kanban can be used in the discovery phase (visualisation aspect can definitely help, but I'm not sure about the focus on flow), but I am yet to be convinced that flow metrics can drive positive outcomes in such circumstances. More dispersion/variability can be allowed in certain situations, I reckon. What you measure drives behaviors despite the targets
Summary :
In this blog post, I shared my experience about how I use flow metrics. They are great and can be used along with some charts to see whether there are any opportunities to optimize predictability, efficiency, and effectiveness. The effectiveness part worries me from time to time when there is too much emphasis on using flow metrics, though. For optimization, different perspectives have to be looked at. Having goals can help maintain a good balance.
What is your experience with flow metrics?
Comments