Using Flow Metrics in Your Sprint Events
I already talked about how to use Monte Carlo (MC) Simulations in your Scrum Events. However, if your team is just starting with focusing more on flow, that might be complicated or not yet possible due to the lack of data. An alternative would be to use the flow metrics defined by the Kanban Guide.
In this post, I’m explaining the four flow metrics briefly and suggest how you can use them in your Scrum Events.
What are Flow Metrics?
What I call flow metrics here are the “four mandatory measures to track” according to the Kanban Guide. Let’s quickly look at each of them.
Work In Progress (WIP)
The number of work items started but not finished.
— The Kanban Guide
This measure tells you how many items are currently started, but not yet finished. Having too much in progress will slow down your ability to deliver. On the other hand, if you’re not having enough in progress you are not operating as effectively as you potentially could.
Throughput
The number of work items finished per unit of time. Note the measurement of throughput is the exact count of work items.
— The Kanban Guide
Throughput shows the speed of your team. Following are examples of throughput:
- 2 items per day
- 11 items per week
- 15 items per Sprint
An important distinction from throughput to velocity based on Story Points (or other estimates) is that it is counting the items. It is independent of the size of the items. If on a single day, you close two items, one that you have estimated with 2 Story Points and one that you have estimated with 13 Story Points, your throughput for this day is 2.
Work Item Age (WIA)
The amount of elapsed time between when a work item started and the current time.
— The Kanban Guide
Once you start to work on an item, you can start to count the time this item is in progress. Usually, this is done in days. The more an item is aging, the more attention should be put on it.
It’s a leading indicator that a team can act upon. Especially if the age is visualized, it helps focus on it.
Cycle Time
The amount of elapsed time between when a work item started and when a work item finished.
— The Kanban Guide
Once an item is done, its current Work Item Age becomes its Cycle Time. It’s the amount of time it took to close that item from start to finish. While WIA is useful per item, the Cycle Time is very interesting when looking at multiple items.
With a Scatterplot over the last days/weeks/months you can see how fast you close items. Instead of relying on an average (beware of the flaw of averages), you can see different percentiles like:
- 50% of all items were closed in 7 days or less
- 85% of all items were closed in 16 days or less
This allows you to forecast how long a single item will take to complete with a given certainty.
Using Flow Metrics in Your Sprint Events
As we have an overview of the four flow metrics now, let’s see how we can use them in our Scrum Events. There are already other posts that look into this topic, feel free to check them out as well to get another perspective.
The advantage that flow metrics bring to your events is that they will be more data-driven. And you don’t have metrics that are based on estimates, but all are real data that show how your team has performed or is currently performing.
Sprint Planning
If you don’t use a forecast based on Monte Carlo simulations, using your historical throughput is a good option to get a feeling about how many items will fit in your Sprint.
You can either check your throughput for the last Sprint and use this as input. This would assume your next Sprint will look like your last one.
Otherwise, you can look at more historical data, and for example, check the throughput for the last couple of Sprints. You could then calculate the percentiles you are interested in — for example the 80th and 50th percentile (aka the median).
In the below chart you can read that in 80 percent of the Sprints, the team managed to have a throughput of 22 items or more. In 50 percent of the Sprints, that team managed to close 32 items or more.
These numbers can then be used to plan your Sprint. be the number of items you plan for your Sprint. For example, you can plan for 22 PBIs, as this is an amount of items you’ve managed in the past in most Sprints.
Why use Throughput over Velocity in Sprint Planning?
Now you might wonder why you would use the Throughput as input to your Sprint Planning and not for example your Velocity based on Story Points.
Throughput is the past performance of the team. What you see happened already. When we use the numbers from the Throughput we’re assuming the future of the team will look somewhat similar to its past.
Story Points are a good tool to foster shared understanding and make sure we’re not having too big PBIs. However, they allow relative sizing and don’t connect to time spent. Your 4 Story Point PBI may be taking longer than the one estimated with 13 points. Are you then removing points from that PBI so it matches? If not, will your velocity be meaningful to predict how much will fit in the next Sprint?
With Throughput, you don’t have to have such discussions. It’s also easier to understand for most stakeholders. “how much” we’ll manage makes just more sense than thinking in “effort” and then trying to apply some conversion formula to get to a time.
While Story Points can be useful, I do prefer working with Throughput. At the very least, we can include items without any big “estimation discussion” before or during a Sprint Planning, allowing the team to focus on the purpose of the Event.
Using the Work Item Age in the Sprint Planning
On top of this, it might be a good idea to look at the Work Item Age of the items that are still in progress when you enter Sprint Planning. This could give you an indication if they will be about to be finished according to your normal Cycle Time or if they might continue for some longer time. This could help you make a decision whether you even want to proceed working on those PBIs or stop and focus on something else instead in the next Sprint.
Daily Scrum
During the Daily Scrum, the Developers meet to create an actionable plan for the next day of work that helps them move towards achieving the Sprint Goal.
Using Work Item Age in the Daily Scrum
Work Item Age is a key metric for the Daily Scrum. It helps you show which items are aging more than others. This should be a signal for the team to act on those items and figure out why it is aging.
In our teams, WIA is driving the bulk of the discussions during a Daily Scrum:
- Is it blocked? If yes, what can we do to unblock it?
- Can someone from the team support the people that are already looking at this item? Should perhaps the full team focus on it?
- Should we split this item into multiple items? Is there something that can we close earlier that still delivers value?
Visualizing the WIA, either on a board with colors depending on the age of the item, or in an “Aging Work in Progress” chart as shown above from Actionable Agile helps guide the team in their discussion.
Using Work In Progress in the Daily Scrum
Another metric that might be valuable is WIP. Are we having too many items in progress and clogging up our development pipeline? Equally important, are we having enough work ready in our pipeline or should we invest in refinement, as otherwise we will run out of work?
During our Dailies, we often identify that we need to refine some items so they are ready to be worked on by the team. The trigger for this is that the number of PBIs in progress is below our WIP limit.
About WIP Limits
Remember, if you work with WIP limits, this is both an upper and a lower limit that you would like to achieve. It’s the presumed ideal state and we should neither be above nor below this.
Let’s assume you have a column-based WIP limit in your workflow and you have the following columns:
- New (No Limit)
- Refinement (WIP Limit: 3)
- Implementation (WIP Limit: 5)
- Done
You don’t want more than the respective amount of PBIs in each column, as otherwise, you are “clogging” up the delivery pipeline. You won’t get “flow”. However, you also don’t want to be below. Let’s assume you have only 1 item in Implementation, I would assume that would not make the stakeholders happy. If you have 0 items in Refinement, you might run out of work soon. Again, you won’t have a nice flow.
If you pull an item from Refinement to Implementation, it should be a trigger that you pull in a new item from New to Refinement. If our current state deviates from this, it’s a signal that you should adjust. And a perfect topic for a discussion in a Daily Scrum.
Sprint Review
In a Sprint Review, we want to “inspect the outcome of the Sprint and determine future adaptations”. As we expect to have stakeholders in the (virtual) room during this event, they might have questions about the future of your product, that sound something like this:
- When can we expect Feature X to be done?
- I raised a critical Bug last week, will you be able to close this before the big customer demo next week?
For those questions, your Throughput and your Cycle Time will be helpful. With information about your Throughput, you can give a forecast about how long it will take to complete a certain set of items.
Note: While Throughput will work for this, I would use it with a Monte Carlo Simulation if you have this available.
With a Cycle Time Scatterplot, you will be able to answer how likely it is that you manage to close that bug before a certain date. “There is a 95% chance that we will manage” or “There is a 40% chance that we will manage” will trigger different discussions. And that’s why we’re having the Sprint Review, to collaborate with all participants on what to do next.
It could also be an option to inspect trends, both in Throughput and Cycle Time in the Sprint Review. If they are getting better over time (more Throughput/lower Cycle Time/Percentiles in Cycle Time Scatter Plot getting closer together) or worse, this might be triggered by a change in the environment of the Product, Team, or Organisation. Those are all things that you want to discuss with your stakeholders.
Sprint Retrospective
In the Sprint Retrospective, it’s your team’s chance to inspect how you work and try to increase quality and effectiveness.
Various Flow Metrics can be useful for this:
- Do we have outliers with a high Work Item Age/Cycle Time? Should we analyze what happened with these PBIs and how to prevent it from happening again?
- Is our Throughput decreasing? If so, what is causing this?
- How could we lower our Cycle Time and bring the percentiles closer together?
- Is our WIP ok? Should we increase or decrease it?
All of this can be valuable input for your retrospective. I would recommend inspecting this on a regular base with your team. It does not need to be in every retrospective, but in case you observe some trends (positive or negative), it might make sense to make this transparent and look at what caused this.
Discuss about Facts during the Retrospective
One big advantage that Flow Metrics have is that they are “facts”. They show what happened. It’s not about how to “estimate” better or how to increase Velocity (let’s just estimate more…). This PBI has been in progress for 32 days. We did manage to close 12 PBIs this Sprint.
In my experience, this has lead to better discussions within the teams about how to improve. The metrics are understood by everyone, which makes it easier to inspect them. And in case there are any actions, it is also simple for the team to check the impact of this action.
All in all, having Retrospectives around Flow Metrics has helped us create more specific actions and made it easy for us to track whether it had an impact or not.
During the Sprint
The Flow Metrics can of course be useful at any point in time during your Sprint. You don’t need any specific event for this. If you observe items that seem to age more than others, you can trigger a discussion right away.
If you have a new “high priority” that PBI enters your backlog, you can check your Cycle Time Scatterplot to have an idea of how long it will most likely take to finish it, before you create an “expedite” lane and take away focus from the team.
And you should always be aware of the amount of work in progress and if it’s matching your WIP limits.
Keep in mind what the Scrum Guide says about adjustments:
If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.
Conclusion
Flow Metrics can be supportive of every Event in Scrum. They support you, your team, and your stakeholders in having meaningful discussions. They also remove the need for other metrics (for example Velocity with Story Points) and thus can free up some time and provide a focus for the full team.
A good thing about Flow Metrics is, that you most likely already have them available. All you need to know is:
- When did we start to work on this item
- When did we finish this item
If you are using a digital tool, most likely the information is already there and could be visualized. Otherwise, it requires minimal effort to capture this data manually.
Give it a try and improve your Scrum Events with Flow Metrics.
