Focus on Flow of Work Instead of Velocity to Track Progress

With an agile team, the flow of work is crucial. We want to move work as fast as possible from “started” to “completed” so that we can get feedback on what we’ve done and learn whether it created the value we expected. There is no golden rule on how fast work should flow. It all depends on your specific context. A great way to visualize a team’s flow is by using Value Stream Mapping (VSM) to discover bottlenecks and areas for improvement.

Benefits of Flow

Continuous flow has many benefits:

• Enables faster and more sustainable value delivery
• Helps us build in quality through steady and consistent feedback
• Creates a line of sight to value and the impact we’re having
• Ensures test and validation work keeps pace with development
• Makes it easier to “shift left” with security, governance, and other essential protocols

Flow Metrics

The metrics of flow are very different from traditional scrum-style metrics. Instead of story points and velocity use the following:

• Work in Progress (WIP)
• Lead and Cycle Time
• Throughput

These flow metrics are preferable to traditional scrum-style metrics because they are more actionable and transparent. They show more clearly where teams have opportunities to improve and give more insight into the flow of work. Our own Hunter Tammaro and Julie Wyman have written on the importance of flow metrics. For more details about their value, check out this blog on how they improved work at Siemens.

If you’re uncertain about using flow metrics instead of velocity, review Bill Hanlon’s work. He looked at ~60 projects that used relative sizing estimates and compared their predictions to actual performance. Then he reset all their estimates to 1, recomputed their velocities, and compared those to actuals. He found a 97% correlation in predictive accuracy between the two methods. Using relative story point sizing—and the effort that comes with it—gives only a very small benefit.

Flow Metrics Defined

WIP

WIP is any work item (e.g., user story, defect, etc.) between “started” and “completed.” These boundaries will vary, but it is important to recognize how early WIP begins to count against a team’s cognitive capacity. The Zeigarnik effect ensures people remember uncompleted or interrupted tasks better than completed ones. Therefore, uncompleted work occupies our brain, even if we haven’t started it yet.

Cycle Time

Cycle Time is the length of time a work item spends “in progress.” It’s useful to measure days from “started” until “completed.” Lead Time is slightly different, and it measures the time from when an item is accepted by a team until the time it is completed. It might be the time from “ready” to “completed.”

Throughput

Throughput is the number of work items that are “completed” per unit of time (e.g., work items per week). It is different from velocity, which measures story points per iteration. Throughput counts the number of work items completed in a specific span of time. That span could be days, weeks, months— or even iterations.

Little’s Law

Flow metrics—WIP, Lead Time, and Throughput—are linked through a simple yet powerful formula known as Little’s Law:

Avg. Lead Time = (Avg. WIP) / (Avg. Throughput)

This formula allows various calculations and estimations. If you have WIP and Throughput, you can estimate your Lead Time. Similarly, if you want to reduce Lead Time, you can use your existing Throughput and calculate a lower WIP that should allow you to achieve that Lead Time.