The Lead Time and Cycle Time Debate: When Does the Clock Start?

lead time and cycle time

Recently, a group of my LeanKit 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 LeanKit, 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.

cycle time

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.

Recommended Reading:

To learn more about lead and cycle time, we recommend these resources:

Tommy Norman

Tommy is the Lean/Agile Coach at LeanKit, ensuring that we embody the values and principles behind our product. He's the director for the Agile Nashville user group and the Music City Agile conference, and frequently speaks at local and national events. Tommy is a 9-time Microsoft MVP. His Agile training series has been the top selling Agile videos on Safari Books Online for the last two years. Connect with him @tommynorman.

9 thoughts on “The Lead Time and Cycle Time Debate: When Does the Clock Start?

  1. It seems like this may be confusing the issue more than you want it to. All of this really depends on where the Value Stream you are measuring starts and ends. If you are saying your value stream starts when Product Management first accepts a request from a customer into their backlog, then your definition of lead time is correct. In most cases, though, this value stream has a very difficult SLA to set and deliver on consistently, because the product part of the work can been extremely variable. If, on the other hand, you are saying that the value stream starts when the Product Manager puts a new work item in the dev team’s “ready” backlog, then lead time becomes the time from when it entered that queue, to when it is “in production.” This is a sustainable and predictable lead time SLA to hit, in my experience. Then cycle time is measured as “time picked up for work, to time in production.” Or any other sub-cycle you want to measure.

  2. I love you guys (and gals). Your product has really matured over the last two years. So this comment comes from a real place concern, not a typical rant.

    First, I take issue with some of your definitions. To many this feels like playing semantics, but is it important so that people aren’t confused.

    Second, there is an entire body of knowledge complete is a standards body around these terms. You can’t just go making stuff up based on an internal debate with colleagues and have it effect your product. You have to make your product conform to the standards body definition. That standards body is the Lean Enterprise Institute (LEI). They can be found at

    From a change management perspective, having LeanKit not conform to the LEI standards means that every company that has Lean/Lean Six Sigma initiatives and resultingly already is using the standard definitions is going to criticize LeanKit and undermine the licensing of LeanKit and any Lean Transformation efforts.

    So, the definitions I take issue with: Lead Time and your definition of Cycle Time.

    There are two Lead Times in Lean Management: Order Lead Time (also Customer Lead Time) and Production Lead Time (also Throughput Time and Total Product Cycle Time)

    Order Lead Time (also Customer Lead Time) — “Production lead time plus time expended downstream in getting the product to the customer, including delays for processing orders and entering them into production and delays when customer orders exceed production capacity. In other words, the time the customer must wait for the product.” (p220-223).

    Production Lead Time (also Throughput Time and Total Product Cycle Time) — “The time required for a product to move all the way through a process or a value stream from start to finish. At the plant level this often is termed door-to-door time. The concept also can be applied to the time required for a design to progress from start to finish in product development or for a product to proceed from raw materials all the way to the customer.” (p228-232). This is what you are calling Cycle Time.

    I ask you to change any references in your product to end any confusion adopting your product.


    Lean Enterprise Institute (5th Ed), Chet Marchwinski, John Shook, and Lean Enterprise Institute, eds. Lean Lexicon: A Graphical Glossary for Lean Thinkers. Brookline, Mass: Lean Enterprise Institute, 2014. Kindle Edition.

    “CYCLE TIME.” Lexicon, 2014.

  3. Hi Tommy,

    Glad to see Leankit weighing into the “debate” (not sure I’d call it a debate – more like a dialogue with many people trying to learn). I wrote about my learning just a few weeks ago. I learned that what I was calling cycle time was more properly termed process time. Having worked in manufacturing in the first of my career – we referred to the cycle a machine had to produce to create it’s feature in the part (I’m thinking of a metal press). We may have been using the wrong term – but it stuck.

    So looking up other resources during this dialogue (and I checked LeanKit but didn’t find this debate) I noticed that cycle time has a unit of time per part, not time. That doesn’t appear in your definition. I note that in software dev. we are generally not producing thousands of like parts – but one off stories that are unique, therefore the per unit part is ignored in our industry. Is this what Leankit is doing also?


  4. Thank you for your effort in trying to clarify these concepts. I would politely invite you to review basic Industrial Engineering concepts before continuing as you are making simple concepts in production systems very complicated. I am afraid such complications by many entities have been resulting in very poor gains in implementing lean in the US. Your explanations do not particularly work in reality. Thanks again for sending me a note to view your understanding of lean related to lead time and cycle time.

  5. Michael,
    Thanks for your feedback. While industries like Industrial Engineering may have some very specific definitions for Lead Time and Cycle Time, our product is used by a wide variety of industries, from engineering operations management and software development to marketing teams, and more. Many of these other industries do not have such clear definitions, due in part to the type of work they perform. My goal for the article was to move people towards determining the questions they are trying to answer and the issues they are trying to solve with these metrics. If your particular industry has well defined standards, then by all means you should use those.


  6. David,
    Thank you for adding your voice to the dialogue! I did not mention units specifically and you are correct. To establish some context, our product is used by people in a wide variety of industries, from engineering operations management and software development to marketing teams, and more. While some industries have more defined standards for Lead Time and Cycle Time, many other industries do not. Also, their definition for a ‘part’ can vary greatly. So, I purposefully used the term ‘value,’ which can mean something different to people in other industrues.

    As for whether this discussion is a debate or a dialogue, I think both terms are valid. I feel like it’s a debate because people are passionate about maintaining strict definitions that can be different from one another, and people want to defend their definitions. But what happens when you’re working on a team or in an industry that conflicts with those definitions? At that point, a dialogue is truly necessary to define Lead Time and Cycle Time in a way that works best for that team. My point was really to steer people away from the definitions and more towards using the metrics intentionally to solve their specific problems.


  7. Devin,
    I very much appreciate the feedback and the specific reference. LEI has very specific terms and definitions, but so does Lean Kanban University, various Six Sigma education providers, and many others. All these definitions vary slightly from one another. Since we are trying to help such a wide audience adopt better practices, we tend not to rely on any single organization’s standards. If a customer works in one of those industries that does have set standards, they can simply adhere to the standards dictated by their board design.


  8. Brendten,
    I actually think we are saying similar things. If you look at the paragraph starting with ‘In knowledge work…’, I mentioned that there may be a segment of time when an idea is introduced in which it goes through some scrutiny for prioritization and is then placed in a team’s backlog. Depending on what that team is trying to measure, they may choose to start their own Lead Time clock when it gets placed into their backlog.

    The article was meant to speak to that larger audience of people who work in a wide range of industries that may or may not have as clear definitions and standards around their work. My hope was to help people move away from set definitions and terms, and instead move toward answering their own questions and using these metrics to solve issues.


  9. Interesting to see the “debate” continue on this article intending to:

    “… 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.”

    Perhaps some of us are just like pigs wrestling around in mud – after a while you’ll realize the pig just enjoys the mud.

Leave a Reply