Despite being a fan of Lean and using Kanban I’ve stopped talking about “Cycle Time”. The problem is that there are two conflicting definitions of Cycle Time. And one of those definitions is identical to Lead Time. Given the competing definitions for Cycle Time, and that the variations have alternative unambiguous names, it is easier not to use the term at all. All I need is “Takt time”, “Order Lead Time” and “Production Lead Time”.

Confusion reigns

When reading about Kanban and Lean Software Development in general you will often see Lead Time and/or Cycle Time mentioned. The trouble is that:

• sources don’t necessarily define the terms they use
• different sources define the terms in inconsistent ways
• different sources use different terms for the same thing

Mess.

Unravelling the tangle I’ve found five terms and six definitions:

• Lead Time
• Takt Time = Cycle Time (Definition 1)
• Order Lead Time = Cycle Time (Definition 2a)
• Production Lead Time = Cycle Time (Definition 2b)

Each of the terms on the left – Lead Time, Takt Time, Order Lead Time, Production Lead Time – has a clear definition.

Lead Time

I think Lead time is pretty clear. The phrase is part of common language. When I say “What’s the lead time on that?” I mean “How long will I have to wait?” This definition has crept into the books in various forms.

David Anderson is the creator of LKU Kanban. His book, Kanban: Successful Evolutionary Change for your Technology Business (Anderson, 2010) refers to Lead Time a lot but doesn’t explicitly define it. Having said that, in one place Lead Time refers to the time "from the order into production" (p. 140) and in another as the time from starting work until finished (p. 26).

In fact software teams are interested in two common variations that start the clock at different times:

• Order Lead Time: the clock starts when the customer makes the request and ends once delivered.
• Production Lead Time: the clock starts when work begins on the request and ends when the item is delivered. In software development this is sometimes called “Engineering Lead Time” and in manufacturing “Manufacturing Lead Time”.

Now for the mire around Cycle Time . . .

Definition of Cycle Time 1 = Takt Time

The definition I subscribe to is that Cycle Time is the average time between successive deliveries. This form of Cycle Time has also become known in the English speaking Lean community as Takt time.

Ohno Taiichi (1988), one of the originators of the Toyota Production System, doesn’t refer to Little’s Law but does talk about average Cycle Time.

[Average] Cycle time is computed by dividing operating hours by the quantity required per day. Even when Cycle Time is determined this way, individual times may differ.

Ohno (1988), p. 22

In other words:

Cycle Time = Operating Hours per day / Quantity per day

For example, assume the plant operates for 10 hours per day and need to produce 60 cars each day. The Cycle Time is 10 / 60 = 1/6th of an hour i.e. 10 minutes. In other words, on average every 10 minutes a car rolls off the assembly line.

“Quantity per day” is the same as Throughput for a day, in the example 60 cars per day.

Definition of Cycle Time 2 = Time between points in the Value Stream

George Dinwiddie defines cycle time as “the amount of time it takes for a single unit of work to progress from one identified point in the value stream to another.” For me this is basically Lead Time.

There are two common variants of this: (a) Order Lead Time and (b) Production Lead Time.

Definition of Cycle Time 2a = Order Lead Time

I don’t know why but some folk define Cycle Time as the time the request is in the system making it synonymous with Lead Time.

Mary and Tom Poppendieck are probably the gurus on Lean Software Development. Two of their books (Poppendiecks, 2003, 2007) mention Cycle Time and none mention Lead Time. Cycle Time is defined as the:

• average time it takes something to get from one end of a process to the other (Poppendiecks, 2003, p. 77)
• time from identified customer need to delivered customer value. (Poppendiecks, 2007, p. 98)
• time from customer ‘order’ to deployed software (Poppendiecks, 2007, p. 238)

“Time from customer ‘order’ to deployed software” sounds just like what other people call “Order Lead Time”.

The Poppendiecks (2007) also use the phrase “time from concept to cash” for Cycle Time (p. 238) including in the title of the book. Interestingly Larman aand Vodde (2009) repeat the refrain from "concept to cash" but apply it to Lead Time not Cycle Time = more confusion. This definition – whether Cycle Time or Lead Time – only works in the context of product development, where in a sense the customer orders a concept.

Definition of Cycle Time 2b = Production Lead Time

For some other folk Cycle Time is measured from when the work starts until the item is delivered. This is what other people call “Production Lead Time”.

This seems to be the definition of Cycle Time used by Reinertsen (2009), an authority on Lean Product Development. He defines Cycle Time as “average processing rate” (sounds like Takt Time to me) but also as “time in system for average job”. The latter is confirmed when he describes cumulative flow diagrams; Reinertsen says

The horizontal distance between the arrival and departure line tells us the Cycle Time through the process for an item of work.

I mentioned David Anderson above but two early Kanban adopters, Corey Ladas and David Joyce, seem to share a common definition of Cycle Time that differs from David Anderson’s. David Joyce is the author of the blog Systems Thinking, Lean and Kanban and Corey Ladas is the author of perhaps the first Kanban book Scrumban: Essays on Kanban Systems for Lean Software Development (Ladas, 2008). With a quick skim I couldn’t find Lead Time and Cycle Time defined in Corey’s book, however David quotes Corey on this blog (David Joyce: Lead Time vs Cycle Time citing Corey Ladas) and then used a very similar definition in a presentation at the BBC (Joyce, 2009):

Lead time clock starts when the request is made, and ends once delivered*

Cycle time clock starts when work begins on the request, and ends when the item is delivered.

Cycle Time is more mechanical measure of process capability.

Lead time is what the customer sees.

* some team end once an item is ‘ready’ for delivery

In fact this use of the term Cycle Time, as a synonym for Production Lead Time, has general currency in the Lean-Agile and Kanban community:

• Larman aand Vodde (2009) also say the quintessential cycles times are “order to cash” or “order to delivery”.
• Jeff Patton says “we’ll measure story-by-story how long they took to complete — the “Cycle Time” of the story” and “The difference between the entry date and done date is the Cycle Time”
• Mike Burrows, a well known Kanban consultant, defines “Average Cycle Time = Work in Progress / Throughput”
• A recent Kanban Primer by Julia Wester defines Cycle Time as the difference between the Commit Date and the Delivery Date.

This flavour of Cycle Time also appears in more general Lean literature:

• Coverage Group says Cycle Time (CT) is the “average time in the system” so Little’s Law is “WIP = TH * CT”

Stefan Roock: Kanban – Definition of Lead Time and Cycle Time obviously like these definitions. He uses the Corey Ladas definition of Lead Time and equates "request is made" with the time the ticket is created and draws some nice diagrams to illustrate the concept.

Other definitions

Confusingly, the two Cumulative Flow Diagram (Fig. 3.1 and 3.2) on pages 26-27 of Anderson (2010) both have Lead Time beginning when development work is started and and stopping when the code is ready for testing – that doesn’t correspond to any other definition of Lead Time I’ve encountered.

Implications for Little’s Law

I previously shared my version of Little’s Law for a Kanban team including Work in Progress (WIP), Throughput and Lead Time. We can rephrase the formula to calculate Lead Time:

LeadTime = WIP / Throughput

The question is what happens to the formula with the different definitions of Cycle Time. Different definitions of Cycle Time have a massive impact on the formula.

If you treat Cycle Time as a synonym for Lead time (CycleTime2) then Little’s Law becomes:

CycleTime2 = WIP / Throughput

(This was exactly the point of George Dinwiddie post on the Relationship of Cycle Time and Velocity; he argues that Cycle Time is the inverse of Velocity.)

But if you accept the original definition of Cycle Time, i.e the average time between successive deliveries (CycleTime1), then Cycle Time is the inverse of Throughput and Little’s Law becomes:

CycleTime1 = LeadTime / WIP

Does it matter?

David Joyce: Lead Time vs Cycle Time citing Corey Ladas
finishes by saying "I have found it is up to those within a value chain/stream/network to decide when to start and stop a clock on both Lead Time and Cycle time.".

In some ways I agree with David Joyce. Let team’s do whatever works for them.

On the other hand, the competing definitions of Cycle Time do make conversations difficult between otherwise aligned Kanban/Lean folk. And they also have completely different implications for Little’s Law.

Given the competing definitions for Cycle Time, and that all the variations have alternative names, it is easier not to use the term at all. All I need is “Takt time” (which isn’t very useful in software development), “Order Lead Time” and “Production Lead Time”.

References

Anderson, D. (2010). Kanban: Successful Evolutionary Change for your Technology Business. Blue Hole Press.

Burrows, M. (2012, 14 June). Another look at Little’s Law. Positive Incline.

Coverage Group. (2005, 17 March). Master of Cycle Time: Little’s Law. Author.

Dinwiddie, G. (2014, 11 December). Relationship of Cycle Time and Velocity. Author.

Joyce, D. (24 Apr 2009). Kanban for Software Engineering. Presentation at an internal BBC conference.

Ladas, C. (2008). Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi.

Larman, C., & Vodde, B. (2009). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley.

Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley.

Poppendieck, M. & Poppendieck, T. (2007). Implementing Lean Software Development: From Concept to Cash. Addison-Wesley.

Reinertsen, D. G. (2009). The principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.

Rother, M., & Shook, J. (1999). Learning to See: Value Stream Mapping to Add Value and Eliminate Muda. Lean Enterprise Institute.

Stefan Roock: Kanban – Definition of Lead Time and Cycle Time

Ohno, T. (1988). Toyota Production System: Beyond Large Scale Production. Productivity Press.

Wester, J. (2014, 31 August). Kanban 101 – A Primer. Prezi.

Wikipedia: Little’s Law