If we look better, we will realize that there are many conceptual differences between the differences of what Lead Time and Cycle Time represent.
And during all this discussion we see that there are no rights and wrongs. Only definitions with understandings come from different literary strands, where each one must have its own line of thought and their arguments for it.
So, the most important thing, in this case, is to choose a definition that makes the most sense and align it indoors. Standardizing a common concept for everyone in the organization should avoid several future problems, believe me! 😅
However, the definition we want to share here as a recommendation is a concept defended by the Kanban community. Being the most widely adopted on the market in recent years, this concept is defined as follows:
Customer Lead Time
It’s the time it takes you to meet a customer’s need, from the request point still in Upstream to the final delivery in production, going through your entire workflow, from end to end. It has to do with your speed of response to the market (time-to-market).
It is important to mention that in the Backlog point of this example, we consider that there is already a previous superficial understanding, where there is minimal knowledge of the need to be solved; and not just orders dumped in any way there.
Lead Time
It’s the time it takes you from replenishment to final delivery. So, if you work with sprints, your Lead Time should probably start counting towards the end of Planning, which is where replenishment and commitment to a new batch of work take place.
It is also important to mention that ideally, your Lead Time should count until delivery in production (where the customer can already enjoy what was delivered). However, there are some cases where the team does not have autonomy until this stage. For these cases, we can consider the endpoint as the moment when the team’s work ends.
Cycle Time
It’s the time between any other two points you choose to measure, it’s customizable. For example, we can understand that it makes sense to measure the Cycle Time of the development stages, or approval, tests, etc.
It is worth mentioning that both measurements are always accounted for in calendar days, prevailing the customer’s perception and avoiding several unnecessary complexities as well.
If you take your car to the garage on Wednesday and they return it to you the following Wednesday, your perception as a customer is that the garage took a week to solve your problem, isn’t it?
Did you know that you can extract all these metrics very easily? Our Team Care BRQ solution is an essential tool for managing metrics. Check out!
João Paulo Grabosque, BRQ’s Agile Coach
