The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban

Before addressing the question of which terms you should use in the Kanban method, let me attempt an explanation of the generally accepted meaning of these terms. (We'll come to the question of how generally later!)

Firstly Cycle Time: it is the time between units emerging from a process. You could visualise it like this:

Our system here could be a Development Team say, and the units User Stories (although we would expect to have more variation in this case). Equally it could be a bicycle assembly plant (working not very fast). The Cycle Time here is half a day because the system produces one unit every 0.5 days. Therefore the Delivery Rate (which is Kanban's preferred term for measuring throughput) is 2 units per day.

To understand Lead Time we need to put a marker on one of the items entering the process, and then see how long before that particular item emerges. Like this:

Lead Time is the time taken for one unit to pass through the process. So our Lead Time here is 5 days.

Now before we consider Little's Law, can you look at those 2 pictures and tell me how many units of work there are in progress in the system under study (WIP)?

Scroll down when you've thought about it...






Scrolling...






Still Scrolling...






Nearly there...




Anyone say 10? That wasn't too hard was it? You've just derived a simple application of Little's Law for a regular (and "stationary") process, and you probably found it easier than plugging the numbers into Little's Law itself:

Delivery Rate = WIP / Lead Time

or

WIP = Delivery Rate * Lead Time
WIP = 2 * 5 = 10

So Cycle Time (as defined here) and Lead Time are very different concepts. However there is one important case where they are equal... when there is only one unit in progress in our system (plug WIP=1 into the formula if you doubt this, or change the Lead Time in the example above to 0.5 days and visualise what is happening). Whenever WIP>1, Lead Time will be longer than Cycle Time.

Why not use Cycle Time in Kanban?

Ok so if that's what the terms mean, why shouldn't we use Cycle Time in a Kanban context?

Put simply, because people use different terms to mean the same thing, and - even worse - the same term to mean different things. And the worst confusion is associated with the terms Cycle Time and Lead Time.

There are authoritative sources from well-respected authors that use Cycle Time to mean something different to its common usage in manufacturing circles (the meaning explained above). This inevitably leads to a whole bunch of confusion. This is why a session at the recent "Kanban Leadership Retreat" (#klrat) led by +Dan Brown sought a common policy for use of these terms in Kanban. They proposed a first step which was that the terms recommended by Kanban for use in Little's Law should be Delivery Rate, Lead Time and Work In Progress (WIP). Furthermore it proposed that the use of Cycle Time should be deprecated, and its reciprocal Delivery Rate should be used instead.

I happen to agree and support this proposal, but I also think there is a necessary second step: to understand what Cycle Time is, as defined in manufacturing, so that you can explain why we use Delivery Rate in Kanban instead of this term as the measure of throughput, and also so that you can explain the Kanban terminology to those who wish to use Cycle Time and Lead Time as synonyms... and hopefully persuade them to adopt the agreed Kanban terms instead.

Good luck!

See also: Why I don't use cycle time in Kanban and Glossary Proposal

Notes:

See also: the  list of terms and definitions that you need when measuring flow and efficiency in Kanban, posted previously.

I'm indebted to this Harvard Business School archive from the year 2000 (which uses Professor W. Bruce Chew's glossary) for the clearest explanation of these terms I've seen so far [http://hbswk.hbs.edu/archive/1460.html], also for the discussion of cycle time In Womack and Jones' "Lean Thinking" (1996, 2003),  and for this blog [http://www.isixsigma.com/methodology/lead-time-vs-cycle-time/] from Fang Zhou which also gives a very clear explanation and was my source for the HBS page .

I'm also very grateful to all those from the Kanban community who have put up with my badgering  and whining about this issue over the last few weeks! Their comments have helped me clarify the issue and decide how best I can explain it to my clients.

In accepting Lead Time as the preferred term for the time taken by one unit passing through the system, the Kanban community has to acknowledge some problems, particularly that some people wish to use this term only for the time from customer order to delivery (which is why qualifying this term, e.g. System Lead Time, may be needed). Little himself used "Wait Time" (because his context was queuing systems). However he also suggested the term Flow Time, which is certainly another good candidate for an unambiguous term.