HomeBlogGuest PostAgile MetricsLead Time Experiment: Calculating Lead Time of the whole process

Lead Time Experiment: Calculating Lead Time of the whole process

In my last years as an Agile Coach, I have been testing new methodologies in order to improve them and be more agile. I used Monte Carlo Simulation (Forecasting software project’s completion date through Monte Carlo Simulation), limited the WIP of our process (Case Study of a WIP Limit Implementation: Why, When and How to use WIP Limits) and now I would like to open a discussion on lead time boundaries – in which step of the process to start and end lead time (LT) measurement.

I used to measure LT by calculating the time that a story would take to move from a “Developing” column until the end, usually the “Done” column, which means that the story is in production. However, a project of which I was involved made me question that definition.

It was a project in which the bottleneck of the process was before the developing process: the UX designing phase. We couldn’t see it in numbers, because it was not being measured. The only way it was possible to spot it was based on the team’s feelings. After the successful end of the project, we had an internal retrospective ceremony in which we’ve stated that if we had concrete information on the UX phase, we would be able to act on it earlier.

One of the alternatives that we found, would be to measure the LT of the whole process, from “Input” to “Done”. And that is what we did in our latest project, the new Elixir Radar channel project, and we would like to share our insights on it.

The Experiment

The project had the following Kanban board at the beginning:


Our team defined LT as the time a story would take to go from “Refining” until “Done”. We chose “Refining” instead of “Input” because, at that moment, we would only start working on a story from “Refining” on.

However, we saw that we still could not answer a question: “What are the next X stories that you want to be done in Y weeks?”. To do that we would need to limit the WIP of the “Input” column and start measuring the LT starting at that same column. So, as explained in WIP-limit blog post, we limited the “Input” WIP, and cut off the “Refining” column, since a card would stay on it only for a few minutes (in our team a refining meeting had a very low cost to be done), and we started calculating the LT from “Input”.


One of the results that we got from those changes was the fact that now we could inform the Product Owner how much time it would take us to deliver an item. We believe that information is what really matters to them. Measuring from “Developing” to “Done” would not satisfy the P.O.’s question, because a lot of work is done before a feature is ready for development.

This little change in the measuring process also gave us extra information on the Lead Time Breakdown chart. As we could now see the amount of time spent in the early stages of the process, we could also limit the WIP in columns like “Ready to UX” and “Ready to Dev”, which has lessened the time spent on those columns and reduced the total LT.

This extra information also helps the communication with high-level stakeholders that want to know where the time is being spent in your project.

We also noticed that extending the LT to all the parts of the process reinforced the image that everyone is working together on the project. That made the PO and UX designer of the project get much closer to the rest of the team.

On the other hand, it is important to say that measuring earlier stages of the process may scare the team at first because the LT values will grow. The industry is used to have the feeling of productivity related to developing, testing and deploying cycles.

Therefore, we think that instead of making a complete transition from a developing-to-end LT to a whole-process LT, one should actually maintain both metrics at the same time. With both, you can still control your development team improvements (with all the historical data that you already have) and start monitoring the rest of the process.

We also had an insight that it may also make sense to calculate the LT of sub-processes that make up a working system. For example, one could possibly calculate a UX LT by measuring the amount of time that a story spends to go through all stages related to UX. But that’s a subject for another blog post…

What about you? How do you measure lead time? Did you like our approach? Tell us what you think in the comments below.

SourceLevel Logo White

Analytics for Engineering Teams. Engineering Ops Platform.


Contact us


440 N Barranca Ave #5351
Covina, CA 91723

United States

© 2024 Caliper Metrics, Inc. All Rights Reserved.