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”.
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
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.
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.
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”.
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.
After some study I came to a conclusion on cycle vs lead. My conclusion was that the experts can’t agree. As you stated, the important thing is to understand how to apply the concepts in your domain. Here is how I’ve come to think about it cycle vs lead.
Cycle time is the time it takes to produce a widget from soup to nuts. Cycle time is going to tell me how efficiently my process and resources can produce a single widget. Optimization of queues internal to the process is going to reduce my cycle time.
Lead time is the time between widgets coming off the assembly line. This is going to give me an idea of how long the customer is going to have to wait. This definition seems to fit how I heard the the term being used in the 1980s when I worked in sales. “What’s the lead time for getting a new IBM PC?”
So to be useful, Cycle Time is a metric that focus’ on improving the production time. Lead Time is more about my overall capacity to produce.
Agreed Tim, there is little consensus. You’ve added a new twist. “Time it take to produce a widget” is normally called Lead Time and “time between widgets coming off the assembly line” is Takt Time i.e. one of the variations on Cycle time.
Steven, once again you’ve taken a topic I’m stewing on, and succinctly researched, summarised, and shared the knowledge. How you manage this on top of your erstwhile day jobs I’ll never know! (well I could ask you or search your blogs!!). 5stars as ever.
Thanks Myles. Sometimes I don’t know how I’m going to squeeze out another blog post either.
Thank you for this post! We have been having a rather animated discussion in my office about cycle time and it turns out that the heart of the disagreement is that we were all using the same term with different definitions. In fact, we were using all of the definitions you have enumerated.
It does get really confusing when different definitions are in play. Every time I heard somebody talk about Cycle Time I thought to myself “hang on, that doesn’t sound quite right. But I’m not quite sure what is wrong”. However, over a few years I collected enough evidence to write up my concerns. Et voila!
Steven, Congrats on completing this research and your conclusions. I only have one small problem with it. The definition of Takt time used in the Six Sigma world is not something you calculate from your process but it is Defined by your customer demand for your product or service. Takt time is the ‘Demand time’….the time that you IDEALLY will take to turn out each consecutive product or service in order to keep up with customer demand for that products or service. The ideal CYCLE Time is one that is Equal to TAKT Time. This will make then stop both delays for the customer and also stop over-production. Correct me if I am wrong, but I don’t think this definition or Cyle and Takt time appears in your analysis ? Thanks. John Dennis
Spot ont. Cycle time, and the term cycle is indicative of this, is the time it takes to go from one product to the next, from a production perspective.