Stefan Roock

All About Agile and Lean

Kanban: Definition of Lead Time and Cycle Time

Important: Cycle time as a concept can have multiple meanings. This blog post uses just one specific meaning. Alexei Zheglov has a more accurate discussion of the cycle time concept.

When doing Kanban for software development measuring cycle and lead times is important but often the terms are confused or defined in a fuzzy way. Here is a useful definition from the „Lean and Kanban“ blog:

Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Lead time is what the customer sees.

Let’s have a closer look and let’s assume we are working with Kanban in a maintenance team. Bugs are reported via tickets in a ticket system like Bugzilla, Jira or Mantis. When the bug is detected a ticket is created and when the bugfix is live, the ticket is closed. This whole period of time is the lead time. The lead time is the time and not the effort. You may have a lead time of 100 days and only have to work 1 hour to fix the bug. Sometime you start working on the bug. The cycle time is the time from the start of the work until the bugfix is live. Again the cycle time is not the effort. Lead time can’t be shorter than cycle time. Often lead time is a lot longer. In the context of maintenance there is often a SLA (Service Level Agreement) in place that defines in which time frame you have to fix a bug. Often the SLA defines a resolution time. That is the same as the lead time: Most SLAs also define a response time. That is the time available until the team has to respond to a new bug ticket: is it really a bug and what is the priority. With these definitions in place it is obvious that the lead time is what is relevant from the business perspective. The cycle time is what the team can influence by itself by changing its work process. To reduce lead times one can (and should) reduce cycle time. But often the time before the work starts is really long so this wait time should be reduced also.

Published by

46 Antworten zu „Kanban: Definition of Lead Time and Cycle Time”.

  1. Nice article and thanks for the IMO clear drawings.

    „The cycle time is the time from the start of the work until the bugfix is live.“ I disagree. The cycle time ends when the bugfix is _ready_ to be live. It’s like the „Lean and Kanban“ blog states: “ Cycle time clock … ends when the item is ready for delivery.“

  2. Hi Bernd,
    you are right.

    I think that is up to you how you want to define the end of the cycle time: ready for delivery or delivered. That seems to be a discussion similar to the Done-Done vs. Done-Done-Done discussion in Scrum.
    We startet with your definition „cycle end time is when the item is ready for delivery“ but we discovered that delivery was a challenging process and that it is under the control of the team. Therefore we decided to use „delivered“ as the cycle time end.

  3. We have a story which analysis has been completed, so we moved it from ‚Analysis Pipeline‘ to next state ‚Development Buffer‘.

    Then the Product Owner realized that some definitions were missed, so.. should the story be moved back to ‚Analysis Pipeline‘?

    We have a property which is ‚Analysis Completed On‘ (that we use for metrics.. to calculate the time stories spend ‚In Analysis‘), that would be reset. Is that ok? Or should we not move the story back to ‚Analysis Pipeline‘ and complete those pending definitions leaving the story where it is.. in ‚Development Buffer‘ state?

  4. Hi Kevin,
    you can move the ticket back or leave it where it is. Both is possible. I prefer to not move tickets backwards.

    The answer to your metrics question depends on what you want to learn from the metrics.

    In your case Analysis wasn’t really done. Therefore it seems reasonable to reset it.

  5. […] Kanban: Definition of Lead Time and Cycle Time March 2010 7 comments 3 […]

  6. […] my interest in Agile and Lean I started wondering what my lead and cycle times for my articles were. Luckily, ReadItLater has an API. My thought is to track when new articles […]

  7. […] tasks). We are not starting the clock when the ticket or task has been created (as described in Stefan Roocks Post), although this seems very reasonable especially for requirements from other teams. Why measuring […]

  8. […] la métrica más conocida del Kanban es el “lead time”, normalmente se suele utilizar también otra métrica importante: el “cycle time”. El “cycle time” mide desde que el trabajo sobre una tarea comienza hasta que termina. Si con […]

  9. Understanding Little’s law is important to understanding lead time (LT), cycle time (CT) and throughput (TP):
    LT = WIP * CT = WIP / TP

    This means:
    1. LT is not equal to CT
    2. CT is the time between two tasks to pass a certain point, e.g. enter the done column.
    3. The definition above is not right

    See also for definitions.

  10. Hi Michele,
    I should have made clearer that regarding Cycle Time it was the definition we used in a project. Regarding software Kanban I don’t see a shared definition of what Cycle Time is. The Cycle Time definition from production doesn’t seem to be very useful.
    David Anderson once said that Cycle Time is up to you definition, simply what you want to measure.

  11. With all respect to David Anderson, Henrik Kniberg and other proponents of Kanban, I think they missed out a little when it comes to the functions we need for various calculations. Also, since this is not a new idea (Lean, Toyota JIT and Little’s law) we shouldn’t need to redefine these concepts and definitely not come up with arbitrary ones. I also see from other comments and blogs, that I am not the only one being confused about this.

  12. This question may sound stupid: Do you count calendar days or work days? With all our public holidays and the weekends calendar days are not very precise for comparing {lead,cycle} times. Thanks a lot for any input. S.

  13. Hi S.,
    that is an interesting question. Counting work days is more precise, counting calendar days is easier. When the average lead/cycle times were longer than a week I used calendar days. One or two additional days don’t affect tge average cycle/ead time too much. In the rare cases were the average cycle/lead time was less than a week I used wirk days.
    If you have to comply to a SLA you would of course the approach that is defind in the SLA.

  14. […] Personal Kanban is helpful here because we can begin to track the amount of time it takes to actually complete our work. There are two metrics here: Lead Time and Cycle Time. […]

  15. […] the last cadence you should start with a first debrief: Lead time is… (If you need some good explanation check here.) The SAC is exactly what can be seen on the pin board. (mirrored horizontically) […]

  16. […] la métrica más conocida del Kanban es el “lead time”, normalmente se suele utilizar tambiénotra métrica importante: el “cycle time”. El “cycle time” mide desde que el trabajo sobre una tarea comienza hasta que termina. Si con […]

  17. I actually have a tendency to agree with every little thing that
    has been put into writing throughout “Kanban:
    Definition of Lead Time and Cycle Time Stefan Roock”.

    Thanks for all of the details.I appreciate

  18. That might be of interest: „The difference between Cycle Time and Lead Time… and why not to use Cycle Time in Kanban“ by Andy Carmichael Andy claims that cycle team equals delivery rate.

  19. […] Therefore it is necessary to include also objectives that show that people are working, such as lead time in kanban or team’s velocity in scrum. Finally, focusing on discovery of new features, […]

  20. I like this simple description and agree with the sentiment that the exact definition is dependent on your context.

    I’d particularly like to reproduce one of your images (leadtimes3.png) in a talk I’m giving on Kanban. I will accredit it to this post in my talk. Would that be okay with you?

  21. Yes, you can use the image.

  22. I have to deal with machine performances improvement everyday, I’m an automation engineer like many of you, so I developed a powerful android tools to get cycle time just tapping on a button, record every cycle time and export data. I hope you will find useful:

  23. […] it excludes the wait time it sat on the backlog for, but it’s a good place to start. See this link for a great […]

  24. […] loop by getting the testers to test everything in an earlier environment. This reduced the total cycle time to deliver bug-fixed […]

  25. […] cycle time analysis, user stories with complexity estimates can be reconciled to the amount of time they took […]

  26. I had this discussion with David Andersion a couple of weeks ago and he also agreed there is some confusion between cycle time as mentioned above, and production cycle time as used in manufacturing processes where CT = 1/TP.

    I’m not saying the article is not valuable though. It’s just semantics.

  27. Very good and clear definition.

  28. Great article. There’s a lot of confusion on this topic as some folks use the terms interchangeably.

  29. […] one can easily also measure the time from when a story is added to the queue until it is done (lead time). This makes it easier to get an idea by when a story will be finished once it is added. This is […]

  30. […] one can easily also measure the time from when a story is added to the queue until it is done (lead time). This makes it easier to get an idea by when a story will be finished once it is added. This is […]

  31. My understanding is that Cycle time is from when the team commit to the work i.e. the ready queue. The cycle time ends when its release i.e. when value is realised.

  32. Avatar von Athresh Krishnappa
    Athresh Krishnappa

    A very useful blog. So Wait time+cycle time= Leadtime. Measuring leadtime is what makes sense. Average lead time is a good measure to improve. Most of the times wait time is the culprit!!

  33. It’s only when a change lands in live – that the value is felt by users. Some of the comments (above) define lead time as finishing when the change is *ready* for production as opposed to actually *in* production. This feels like a fudge – lead time finishes when the change is in the hands of the users.

  34. […] to do instead? Just keep a log of the actual budgets needed for tasks. Log just one number: cycle time. It’s quite easy to measure and close to the actual effort expended. If you want more detail also […]

  35. […] Stefan. “Kanban: Definition of Lead Time and Cycle Time“. Stefan Roock (Accessed […]

  36. Nice explanation…I am also planning to use cycle time metric in my project. I have one question here. I want to calculate average cycle time for a sprint. Let’s consider sprint is of 10 days. I planned 4 User Stories having story points 1,1,4,4. All stories start on first day. 3 stories completed on last day but one story having story points 4 spilled and moved to next sprint. Now Here what will be avg cycle time of this sprint. Again in the next sprint, i planned 3 new User Stories with points 1,4,3 and one spilled user story (4 story points) of last sprint. Again this spilled US, i completed in 2 days and rest 3 took complete sprint. So here what will be my avg sprint cycle time.

  37. The Story Points are irrelevant for the Cycle Time. Just start the clock when starting working on the story and stop the clock when the story is done. Average cycle time for Sprint X is „sum of all cycle times of all stories marked done in this sprint divided by number of done stories“. That way the average cycle time in a Sprint may be much longer than the Sprint.

  38. […] – Mary and Tom Poppendieck [3] See: for more depth [4] image design by FreePik) TAG : cross-skilling, Cross-Training« Previous How to get […]

  39. Is there a way to calculate the time between Active and Resolved state for a work item? The reason I am asking is we cannot deploy work items until we get the dependencies cleared. This is affecting our metrics for cycle time.

  40. I assume that the question is related to a specific tool you use. If that is the case: I don’t know.

    Another perspective is that the wait time for dependency clearance is an impediment for maximizing business value and that therefore the long cycle time is an important indicator that you should to something about out. Removing this wait time from the cycle time hides the problem.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

Du kommentierst mit deinem Abmelden /  Ändern )


Du kommentierst mit deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

%d Bloggern gefällt das: