Kanban: Definition of Lead Time and Cycle Time

March 2, 2010 at 12:58 pm 37 comments

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.

Entry filed under: #. Tags: , .

Kanban: Wer will schon ein Bottleneck sein? Scrum vs. Kanban: Ziel und Weg

37 Comments Add your own

  • 1. Bernd Schiffer  |  March 2, 2010 at 4:43 pm

    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. stefanroock  |  March 3, 2010 at 1:02 pm

    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.

  • 4. André Faria Gomes  |  August 2, 2010 at 10:42 am

    Great! very enlightening!

  • 5. Kevin  |  September 24, 2010 at 3:14 pm

    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?

  • 6. stefanroock  |  September 24, 2010 at 7:19 pm

    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.

  • 7. Fabrice Aimetti  |  November 7, 2010 at 6:01 pm

    Hi Stefan,
    Thank you for this very nice post. I’ve translated it into french :
    Regards, Fabrice

  • 8. 2010 in review « Stefan Roock  |  January 2, 2011 at 12:50 pm

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

  • 9. Reading statistics « JP's Journal  |  March 28, 2011 at 11:35 am

    […] 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 […]

  • 10. Visualizing Kanban Lead Time « pete roessler  |  August 27, 2011 at 9:50 am

    […] 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 […]

  • […] 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 […]

  • 12. Michele  |  April 2, 2012 at 1:11 pm

    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 http://www.systems2win.com/c/time_definitions.htm for definitions.

  • 13. stefanroock  |  April 3, 2012 at 7:33 pm

    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.

  • 14. michelemendel  |  April 10, 2012 at 6:44 am

    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.

  • 15. st0rztorz  |  July 22, 2012 at 8:59 pm

    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.

  • 16. stefanroock  |  July 23, 2012 at 5:34 am

    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.

  • […] 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. […]

  • […] 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) […]

  • 19. El Metodo Kanban « Control de inventarios  |  January 21, 2013 at 1:17 pm

    […] 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 […]

  • 20. http://bing.com  |  February 15, 2013 at 11:14 am

    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

  • 21. Bernd Schiffer  |  July 15, 2013 at 9:05 am

    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 http://xprocess.blogspot.co.uk/2013/07/whats-difference-between-cycle-time-and.html Andy claims that cycle team equals delivery rate.

  • 22. Management By Objectives | ReStreaming  |  October 3, 2013 at 7:23 am

    […] 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, […]

  • 23. Nicholas Form  |  October 8, 2013 at 8:18 pm

    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?

  • 24. stefanroock  |  October 17, 2013 at 6:43 pm

    Yes, you can use the image.

  • 25. Fabrizio Avantaggiato  |  December 28, 2013 at 11:46 am

    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: https://play.google.com/store/apps/details?id=com.avafab.cycletime

  • 26. The only software metric you need…  |  March 23, 2014 at 11:25 am

    […] 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 […]

  • 27. Delivery, Delivery, Delivery | Joe Blogs  |  July 13, 2014 at 11:55 am

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

  • 28. Estimation: Ideal days vs. Fibonacci Part 1 | Agile Taõ  |  September 29, 2014 at 4:10 pm

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

  • 29. vvanderh  |  October 15, 2014 at 3:47 pm

    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.

  • 30. Dave Nicolette  |  October 15, 2014 at 4:05 pm

    Very good and clear definition.

  • 31. David Pemberton  |  October 15, 2014 at 4:20 pm

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

  • […] 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 […]

  • […] 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 […]

  • 35. Dillon Weyer  |  February 3, 2016 at 12:13 pm

    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.

  • 36. Athresh Krishnappa  |  March 30, 2016 at 10:58 am

    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!!

  • 37. nigehamilton  |  July 25, 2016 at 10:07 am

    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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Get every new post delivered to your Inbox.

Join 198 other followers

%d bloggers like this: