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.

46 Kommentare

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

  6. 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.

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

  8. 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.

  9. 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.

  10. 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
    it-Benito

  11. 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?

  12. 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.

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

  14. 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.

  15. 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.

  16. 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.

  17. 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.

  18. 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:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

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

Verbinde mit %s