How to Measure Speed


Delivering value fast

Our goal is to develop and deliver value fast. But how can we know if we are really fast?

This is not a trivial question; it causes lots difficulties for organizations and teams to be able to determine how fast they actually are. Let’s take a deeper dive.

Lead time

First of all, in order to be able to measure the speed of the value delivery flow, you need to understand what that flow actually is, in your case. We’re going to measure how long does it take us from the moment a new work item was accepted into development to the point where it has been delivered to the customer. This is called the Lead Time. So, for a new feature that the product manager had on her mind, we would measure the duration from the moment she placed the feature in the backlog to the moment the feature was delivered to the customer and now the customer can use it. Or, for a defect that the customer found in their system, the lead time would be measured from the moment the defect was accepted into work and to the point it has been fixed and the fix was delivered to the customer.

Please note one important thing: while it is quite clear what the end point of the flow is (and that is where something is delivered to the customer), it is not always all that clear as to where is the starting point. There has to be some explicit acceptance of new work into development, which means: yes, we are going to start working on it, maybe not immediately, but we are. And only then the clock starts ticking. So, our product manager may have a gazillion of new feature ideas, but only a few of them will be actually ever worked on and those are the only ones for which care measuring lead time. Similarly, there may be customer defect reports that will never be worked on. But only priority defects, once accepted into work, are the ones for which we measure the duration.

Aggregate measures

So, we know how to measure speed of delivery of one item. But you may be working with plenty of items and this is where some aggregate values are helpful. One of them is the Average Lead Time. If we worked on 23 features in the previous quarter, we might want to know what was the average lead time across all those features.

Cumulative Flow Diagram

A very useful time progression on this could be obtained with the help of Cumulative Flow Diagram or CFD, for short. Here we have time on the X axis and the number of items on the Y axis. CFD consists of two curves: the arrival curve and the departure curve. The arrival curve tells us how many items were accepted into the system over a period of time. The departure curve tells us how many left the system—or, in other words, were delivered—over a period of time. The horizontal distance between the two curves tells us the lead time at that point, and the vertical distance tells us the WIP, or the work-in-progress at that point. A lot of WIP leads to slow delivery. The benefit of the CFD is that it shows how Lead Time (and WIP) change over time. It may also help us see that, for instance, that we started accepting more or less items than before, and so on. And you may have already started to wonder, why there are these bumps on the curve. Those are the actual deployments. This shows us, as a matter of fact, that big, infrequent releases make value delivery slow. And on the opposite, smaller release batches accelerate value delivery. Now, important caution, once again: Lead Time is measured to the point where something is delivered to the customer, so they could use it. It’s not the time till you are ready to deploy, it’s the time to the point you actually released and deployed it.

The CFD can actually be more granular than what we’ve so far considered. Only instead of reflecting just the two extreme points on the workflow, we will also include the steps within. We’ll get something like this. It may be more helpful in locating a bottleneck. However, it is very important to not get overly excited about all this detail and remember that the actual measure of speed rests with Lead Time, a measure of duration from one end to another.

Taking action

As an action item, plan a specific step in improving the way you measure speed of value delivery.


Learn more   

Donald Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing; 1st edition (January 1, 2009). Chapter 3.


Alex Yakyma

Alex Yakyma is the author of “Pursuing Enterprise Outcomes” and “The Rollout”. As a consultant, Alex is helping enterprises succeed with complex challenges. Throughout his career, he operated in multi-cultural, highly distributed environments. Alex has trained a large number of change agents and leaders whose key role is to help their organizations achieve higher effectiveness at pursuing business outcomes.

Explore more content

Improving in the moment

Seeing the opportunity
Read more

Being an Agile developer

Knowledge workers are key to Agile <
Read more

Unit and Integration Testing Overview

The two important types of testing <
Read more
Contact Us