Skip to main content

Glossary Proposal

One of the problems Kanban practitioners have faced over the past several years is the lack of agreement of the terminology to use to describe flow systems. This in turn has led to confusion in both those learning the method and those implementing tools to support it. This blog has made a few previous attempts to disambiguate common terms (see discussions of Cycle Time for example). Mike Burrow's Glossary of Terms, [burr] reproduced on the Lean Kanban University site [lkun] is also very useful, though it does not give guidance on which terms to use when applying Little's Law to sub-processes in a more complex Kanban system. 
This article is another foray into this minefield and is principally a proposal for the definitions of commonly used terms relating to Little's Law, particularly seeking terms applicable in complex flow systems and sub-processes within such systems. It is an invitation to others in the community to endorse these definitions, or propose alternatives. Let's not go another seven years with this unresolved!

Note: This is a work in progress and will be updated from time to time in response to feedback from other authors and practitioners.

The Kanban Method is a process improvement approach based on understanding knowledge work as a flow system. The life cycles of the "work items" in such flow systems are analysed and improvements to the process are made based on observable positive change. So let's start with Little's Law since it is the first basis of understanding flow systems. For a given system it may be defined as follows [litt]:
Arrival Rate = WiP / TiP     
where the overline indicates the arithmetic mean in a "stationary" or other compliant system.
Arrival Rate
Measured in: work items per unit of time (seconds, hours, days. working days, etc.)
Definition: The number of units entering the system per unit of time. The work item must be defined for the metric to be meaningful (e.g whether a User Story, Feature, Case, Initiative, Physical Item, Episode, Request, etc.). Little uses Arrival Rate in his definition of the law. In a "compliant" system the average rate of items arriving in the system and leaving it must be equal:
Arrival Rate = Throughput 
Throughput and Delivery Rate are usually treated as synonyms in Kanban systems. However if a distinction is made between delivered and discarded items (essential if we are to understand productivity effectively), a distinction should also be made between these terms. Since items may be either delivered or discarded:
Throughput = Delivery Rate + Discard Rate 
If the Discard Rate is not significant or we exclude discarded items, we can use the common formulation of Little's Law found in Kanban system analysis:
Delivery Rate = WiP / TiP
If the Discard Rate is significant, the historical values of WiP should include only those items that have been delivered and TiP should be the time in process for delivered items only, not discarded ones. (Alternatively use Throughput and ensure that the time in process for discarded items is included.)
Related terms: Throughput, Delivery RateDiscard Rate, DiscardAbort
References: [ande], [burr], [litt], [vaca]

Measured in: work items per unit of time
Alternatives: Throughput Rate, Departure Rate, Processing Rate [rein]
Definition: The number of work items exiting from the system per unit of time, whether delivered or discarded. See also: Postscript on Throughput and Delivery Rate.
Related termsDelivery RateArrival RateDiscard Rate
References: [vaca]

Delivery Rate
Measured in: work items per unit of time
Alternatives: Completion Rate
Definition: The number of work items emerging complete from the system per unit of time, This is a key metric to understand the productivity of the system.
Related termsArrival RateDiscard Rate, Throughput
References: [ande], [burr]

Discard Rate
Measured in: work items per unit of time
Definition: The number of work items discarded before completion per unit of time. In typical Kanban systems this metric may be significant relative to Arrival Rate, particularly where the "2 stage commit" is used to prepare but not necessarily complete options. Discard is a general term for abandoning a work item. More specifically to Abort a work items means to discard the item after the Commitment Point in a development system
Related termsArrival Rate, ThroughputDelivery Rate, Commitment Point, Abort, Discard

Commitment Point

Measured in: not a metric, a specific point in a defined process
Definition: In a development system process, it is the point at which a commitment is made to develop the work item. Before this point work done supports the decision whether or not to develop the item.
Related terms: Abort, Discard


Measured in: not a metric, an action
Definition: To Discard a work item after the Commitment Point.
Related terms: Commitment Point, Discard

Measured in: not a metric, an action
Definition: To stop work on an item and remove it from the process. Note that an item is "discarded" in this sense even if it might be worked on in the future, for example if the work item is moved back to a queue prior to the system/sub-process under consideration. The term is not specific about when in the process the item is discarded, however in a development system process it may apply to items discarded prior to the Commitment Point, since after this point the term Abort is applicable.
Related terms: Abort, Commitment Point

WiP, Work in Progress

Measured in: work items
Definition: The number of work items which have entered the system but which are not yet either completed or discarded.
Related terms: Arrival Rate, ThroughputDelivery Rate, TiP
References: [ande], [burr], [hopp], [marc], [rein]

TiP, Time in Process
Measured in: units of time
AlternativesCycle Time (but see cautionary note below), Lead Time (when referring specifically to the time in process in a Kanban development system from the Commitment Point to delivery), Throughput Time [modi], Time In System [rein]
Definition: The time that a work item remains in the system or sub-process under consideration prior to being either completed or discarded. This is the key metric in understanding the time to delivery of a system. More specific terms may be derived by replacing "Process" with the particular part of the process of interest, for example "Time in Development". As with all the terms in Little's Law the scope of the system or sub-process under consideration must be well defined to ensure they are meaningful.
A key reason for recommending this term is that it sidesteps the "Cycle Time versus Lead Time" debate which shows no sign of resolution within the communities that use these terms.
Related termsCycle TimeLead TimeTouch TimeTakt Time
References: [macc]

Cycle Time
Measured in: units of time
Alternatives: For CT1 (defined below) use its reciprocal - Delivery Rate; for CT2 use TiP or (where applicable) Lead Time
Definition: The time taken for a "cycle". This is a very ambiguous term which should not be used in Kanban without qualification. Examples of where it is commonly used in the literature are:
  • In a factory: the time between completed units exiting the system [chew], [like], [marc], [woma]
  • For a queue: the time an item remains in the queue [litt]
  • For an airport security control: the (average) time between two items completing the process [modi]
  • For a work station or machine: the time between completed parts exiting the station [chew], [like], [marc], [woma]
  • For a worker/team: the time between starting and completing an item [hopp], [modi], [rein], [vaca]
  • For a project/team: the time between deliveries of completed items [beck]
It is incorrect to use the term for any period which is not contiguous, e.g. Touch Time or aggregated time in a column. Unfortunately such usage may be found in some tool implementations.

Broadly speaking there are two categories of usage for Cycle Time which may be referred to as CT1 and CT2. CT1 is the time between successive items emerging from a station or system. CT2 is the time an item takes from entering the system to leaving it. It is left to the reader to decide which of the examples above are CT1 or, CT2. Note that there is a special case (when WiP=1) where CT1=CT2. Unfortunately this just tends to confuse people further, especially when the example given to define the term is an example where WiP=1!
Where Cycle Time is used in the Kanban community, its definition "generally" coincides with that of Lead Time for Kanban development systems given below.
Author's Note: Since there is no universally accepted definition of what Cycle Time means in a flow system, the term should simply be avoided.
Related termsTiPLead TimeTouch TimeTakt Time
References: [beck], [burr], [chew], [hopp], [litt], [marc] [modi], [rein], [roth], [vaca], [woma]

Lead Time
Measured in: units of time
Definition: In general usage, Lead Time means the time from the request for an item to the delivery of the item (this may simply be the time to get an item from stock or the time to specify, design, make and deliver an item). However its usage in Kanban development systems is more specific. It indicates the time from the Commitment Point to the delivery. For this to be useful the commitment and delivery points must be made explicit.
Note there remains some ambiguity in this term and I would recommend using TiP in most circumstances, and certainly when analysing sub-processes in a larger flow system. If you use Lead Time, qualify it if necessary (e.g. Development Lead Time and ensure that you define the meaning that you wish to be assigned to it in your context.
Related terms: TiPCycle TimeTouch TimeTakt Time
References: [ande], [burr], [marc]

Touch Time
Measured in: units of time
Alternatives: Value-Creating Time
Definition: The sum of all the times during which a work item is actively being working on (excluding wait times, for example being held in stock or in queues).
Related termsTiPCycle TimeLead TimeTakt Time
References: [modi], [woma]

Takt Time
Measured in: units of time
Definition: The projected customer demand expressed as the average unit production time (i.e. the time between the completion of work items) that would be needed to meet this demand. It is used to synchronise the various sub-processes within the system being designed to meet demand without over or under production.
Related termsTiPCycle TimeLead TimeTouch Time
References: [marc], [rike], [woma]

Flow Efficiency
Measured in: %
Definition: The ratio of the time spent working on an item (Touch Time), to the total time in process (TiP), i.e.:
Flow Efficiency = Touch Time / TiP
Related terms: Resource Efficiency
References: [modi]

Resource Efficiency
Measured in: %
Definition: The ratio of the time a resource (for example a person!) is actively working on a work item, to their total available time.
Related terms: Flow Efficiency
References: [modi]

  • [ande] Anderson, David J. Kanban, Blue Hole Press. (2010)
  • [beck] Beck, Kent and Martin FowlerPlanning Extreme Programming, Addison Wesley (2000)
  • [burr] Burrows, Mike. Kanban from the Inside, Blue Hole Press. (2014)
  • [chew] Chew, W. Bruce, Harvard Business School Glossary of Terms [as referenced by Fang Zhou]. (2004)
  • [hopp] Hopp, W.J and M. L. Spearman, Factory Physics, 3rd ed., McGraw Hill, International Edition. (2008)
  • [like] Liker, Jeffrey K. The Toyota Way, McGraw Hill. (2004)
  • [litt] Little, J. D. C and S. C. Graves. Little's Law, pp 81-100, in D. Chhajed and TJ. Lowe (eds.) Building Intuition: Insights From Basic Operations Management Models and Principles. doi: 10.1007/978-0-387 -73699-0, (c) Springer Science + Business Media, LLC. (2008)
  • [lkun] Lean Kanban University. Glossary of Terms, from Kanban from the InsideMike Burrows. (2014)
  • [marc] Marchwinski, C. et al Eds, 4th ed, Lean Lexicona graphical glossary for Lean Thinkers. (2008)
  • [macc] Maccherone, Larry. Introducing the Time In State InSITe Chart. LSSC. (2012)
  • [modi] Modig, N. and P. Åhlström, This is Lean, Rheologica Publishing. (2013)
  • [rein] Reinertsen, Donald G, The Principles of Product Development Flow, Celeritas Publishing. (2005) 
  • [roth] Rother, Mike and John Shook, Learning to See: Value Stream Mapping to Add Value and Eliminate MudaLean Enterprise Institute. (2003)
  • [vaca] Vacanti, Daniel S. Actionable Agile Metrics for Predictability: An Introduction, LeanPub. (2015)
  • [woma] Womack, J. P. and D. T Jones, Lean Thinking, Simon and Schuster. (1996, 2003)


Popular posts from this blog

"Plan of Intent" and "Plan of Record"

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…

Does your Definition of Done allow known defects?

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…

Understanding Cost of Delay and its Use in Kanban

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…