How's Your Team's Flow? Measure it to Master it!

by Hunter Tammaro and Julie Wyman

Why Flow?

Looking for more consistent delivery on your Agile team? Sprint burndown charts are good at showing when work is completed – but they have nothing to say about how the work is done. Fortunately, there are a couple additional metrics that any team can use to put the focus on how the work is actually flowing as they proceed towards delivery.

Flow is the way work moves through a team. The higher the proportion of time a work item spends being actively worked on – as opposed to waiting for available capacity – the higher the team’s flow efficiency. Paradoxically, taking on more work can actually hurt flow by taking away the team’s capacity to address new items as they arrive.

A road is a great example. Consider a highway during rush hour: over-utilization of the road creates traffic jams and slows the flow of cars as they move along the highway. Crucially, purely delivery-focused metrics, because they only measure the rate of output—the number of cars exiting the highway—may overlook the negative impact of such a situation completely.

In absolute terms, observed flow efficiency is typically very low. Knowledge work teams commonly see flow efficiencies of around 5% or less, and even high-performing teams rarely exceed 40%. Part of the reason is that flow efficiency is difficult to measure directly, and trying to measure it can quickly lead to creative approaches to “game” the system. Fortunately, there are other metrics teams can use to understand flow in their work stream, and they are easier to capture.

Lead and Cycle Time

In a robust Kanban system, Lead time is the standard measure of flow. It measures the time from when an item is accepted by the team until the time it is completed. Because Kanban teams typically maintain only a small queue of committed work, work starts on an item soon after this commitment. In this case, lead time is a good measure of the time a team spends working on an item.

Teams not at this maturity level - or with longer backlogs of committed work, like in Scrum - may want a measure more within their control. These teams can still measure how long it takes items move through their team to understand their flow. Rather than the time from commitment to completion, we can measure the time between work beginning on an item and it meeting our Definition of Done. We call this measure Cycle time. (Some sources differ on the precise definition of "cycle time," but this is how we will use it here.) In our experience, by observing trends in the team’s cycle time over the course of weeks and the distribution of cycle times across work items, teams have been able to identify, discuss, and resolve any impediments to good flow, in addition to predicting how long it might take to complete new work items.

Scrum Board

Cumulative Flow Diagram (CFD)

The cumulative flow diagram (CFD) is another Kanban tool to help understand flow. It shows the number of work items in each workflow state over time. The CFD gives a complete and nuanced picture of the way work is moving through a team and can be used to derive averages for work in progress (WIP), lead times, and cycle times at different moments in the past. Learning how to interpret a CFD can take a little while, but is well worth the effort, as it makes both bottlenecks and impediments quickly visible, helping to trigger conversations within the team about how to address them. We recommend this article by Pawel Brodzinski as a great reference for learning more about CFDs.

Cumulative Flow Diagram

What about Scrum? Measuring Flow Within a Sprint

Lead/cycle time and CFDs are core metrics used by Kanban teams to gauge predictability and learn about flow quality. But these metrics can be equally valuable to Scrum teams. Here’s how:

  • Focusing on flow can increase the effectiveness of a Scrum team and improve their chances of delivering on their sprint goal.
  • Using a flow-based approach will allow work to be delivered throughout the sprint, not just at the end, eliminating some of the “start-stop” patterns that often happen with Scrum teams.
  • When stories are delivered throughout the sprint, testers and Product Owners won’t be overwhelmed during the last few days.
  • By completing work sooner, the teams help ensure value is still delivered even if there are late-breaking impediments, shifts in priority, or the sprint gets cut short.
  • By focusing on fewer items at a time, the team can deliver work of higher quality.

Try tracking these metrics on your team and see what discussions they lead to!