The Improving Projects blog from Huge IO (UK & Ireland) is primarily about products, organisations and projects... and how to improve them. As well as musings on agile processes, software engineering in general, and methods like Kanban and Scrum, there's advice here too for users of process planning, execution and improvement tools - and the metrics they can provide. https://uk.huge.io

Search This Blog

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.

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.

Popular posts from this blog

Is it just me or do you also find it odd that some teams have clauses like this in their definition of done (DoD)?... the Story will contain defects of level 3 severity or less only ...
Of course they don't mean you have to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "Done"if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.

Let's look at the consequences of this policy.

Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in…

Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many successful ventures and in a number of SIGs and conferences in which he is active. In spite of knowing Ron by correspondence over a long period of time it was only at JavaOne this year that we finally got together and I'm very glad we did.

Ron wrote to me after our meeting:

I told a number of people later at JavaOne, and even later that evening at the Software Engineering Management SIG, about xProcess. It really looks good. A question came up: It's a common technique in large organizations to keep a "Plan of Intent" and a "Plan of Record" - to have two project plans, one for the business partners and boss, one you actually execute to. Any support for that in xProcess?

Good question! Here's my reply...

There is support in xProcess for an arbitrary number of target levels through what we call (in the process definitions) P…

Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - as is often the case - estimating it quantitatively may be difficult or even impossible. Analysing Cost of Delay (even if done qualitatively) is important because it focuses on the business value of work items and how that value changes over time. An understanding of Cost of Delay is essential if you want to maximise the flow of value to your customers.

Don Reinertsen in his book Flow [1] has shown that, if you want to deliver the maximum business value with a given size team, you give the highest priority, not to the most valuable work items in your "pool of ideas," not even to the most urgent items (those whose business value decays at the fastest rate), nor to your smallest items. Rather you should prioritise those items with the highest value of urgency (or CoD) divided by the time taken to implement them. Reinertsen called this appro…