Recently, a group of my Planview AgilePlace coworkers and I were talking Kanban. The age-old debate surrounding the definitions of lead time and cycle time came up, and we all rolled our eyes a bit. The Lean community has rehashed this topic a million times already, but it seems we still can’t seem to reach a consensus. The topic can be confusing to those new to Kanban, and unfailingly frustrates experienced practitioners. In this post, I’ll explain why these definitions are commonly debated. I’ll also explain how a simple definition can help you make the most of these Lean metrics.
When Does the Clock Start?
The debate surrounding lead time and cycle time is essentially this: When does the clock start?
People new to Kanban often think that lead time refers to the time between when a piece of work is requested and when work actually begins.
The more commonly accepted idea is that lead time starts with a request from a customer and ends when the value is delivered to that customer.
But what is a request? In traditional Lean manufacturing, a request represents a customer order for a physical product.
In knowledge work, a request can be far more intangible: To use an example from software development, it might be an unverified idea for a feature. That idea might have to go through a prioritization process before it’s even put in a team’s backlog. The question then becomes: Did the clock start ticking – when we first had the idea, or when it got added to the backlog?
This is when the definition of lead time and cycle time can get tricky. The terms are often used interchangeably. When this happens, the metrics behind them lose their meaning.
For this reason, some people have replaced the term lead time with more specific terms: customer lead time, for example, or system lead time. This clarifies exactly what is being measured, and for who.
Instead of wrestling with these differences, start with the basics. Ask yourself: What problem am I trying to solve with these metrics?
With All Metrics, First Ask “Why?”
I asked my coworkers this question during our conversation. One of them said, “We need to know cycle time so we know how fast we can produce something.”
“Okay,” I said, “Why?”
This garnered several confused looks, but I pressed on: “No matter how you define them, lead time and cycle time are measures. We’re wasting time debating what exactly they measure.
Let’s take a step back and ask why we want to know this information in the first place.”
The discussion that ensued was much more productive. We all agreed that we wanted to know this information so we could make better predictions about our work.
An Example
Let’s say a new product feature request comes in from sales. Logically, the first question sales asks is, “When can I expect this feature to be done?”
You can estimate that the feature might take about 10 days. But should sales expect to see the feature in 10 days? No.
Why? Because their request is prioritized along with all the other current requests.
Why? Their request is prioritized along with all the other current requests. So if our average time from request to delivery (lead time) is 10 days, and there are 4 items in the queue ahead of this new request from sales, we would forecast that the request would most likely be delivered in 50 days. (10 days per feature, times five.)
Note: We need to be careful with these types of forecasts since using an average doesn’t always reflect the degree of variation that’s common in knowledge work.
How We Define Lead and Cycle Times
Lead Time
At Planview AgilePlace, we define lead time as the amount of time between when a request is made and when it’s delivered to the customer. We often will qualify the term as “customer lead time” to remind ourselves that this metric is from the perspective of the customer.
Of course, we can’t just start every piece of work as soon as the request is made. That would be unsustainable, not to mention unwise. When a request is made, it usually spends some time in the backlog before any work is done on it. To optimize how we do work, we need to look at a more granular metric. This is why it’s valuable to measure both lead time, as described above, and cycle time.
Cycle Time
Cycle time is the amount of time between when work actually begins on a request to the time it’s delivered to the end customer. Cycle time measures all active (value adding) work time as well as the wait states between active work times. It’s useful to measure cycle time to gain an understanding of how efficiently your system operates. Daniel Vacanti just published an excellent post on how to calculate cycle time.
Process Cycle Times
For even more detail, it might be helpful to also analyze the cycle time of individual processes. If you want to know how efficiently your team moves work through the “design” step, for example, you’d measure your design cycle time. For design cycle time, the clock would start when work entered the design lane, and stop when it moved onto the next lane. Measuring the design cycle time for multiple work items would give you an understanding of how long it takes work to move through the design step.
If you’re optimizing each step as much as possible, and your total cycle time is still slow, there may be a simple explanation: Handoffs. For most systems, the majority of waste is in the wait states between steps — not the steps themselves. Measuring individual cycle times can help you identify slow handoffs and other impediments to flow.
Using Metrics Wisely
Lead time and cycle time can help us forecast when items in our backlogs might get completed. This helps us communicate more effectively with our stakeholders.
Investigating process cycle times can help us identify opportunities to improve flow. Decreasing our cycle times means better flow, which means we can deliver to our customers faster.
We need to be careful that our efforts to decrease lead time and cycle time don’t cause a negative downstream impact to other parts of the business (product quality, customer satisfaction, etc.). How fast items flow through our process is only one indicator of how well we are delivering and should be appropriately balanced with other key metrics. Learn more about the dangers of vanity metrics in this post.
As we move away from debating terms to why these metrics are important, we can start to use them effectively in our teams. If we can change the conversation from the “what” to the “why”, we can begin to focus on what really matters: improving delivery of value to our customers.
