In search of unambiguous terminology for Flow systems

Confused by terms like cycle time, throughput, throughput time, lead time, value-adding time, utilisation, flow efficiency, resource efficiency and delivery rate? You are not alone!

One of the fundamentals of agile processes like Kanban and Scrum is that they are about the flow of work. Where older project management approaches have tended to focus on the single batch (the project), processes influenced by the Lean movement (and Toyota's production philosophy) emphasise the flow of work within a project, and of multiple projects. So agilists need to be able to understand, capture data about and improve flow.

One problem in getting good communication between the many experts, teams and sources in this area is common and unambiguous terminology. Just one example from 2 books on my desk at present... how do you express Little's Law (i.e. the law explaining the influence of work in progress on flow):

1. Throughput time = (flow units in process) * (cycle time) 
2. Delivery Rate = (work in progress) / (lead time)

When you realise that some sources use cycle time and lead time interchangeably, meaning the time taken from one point of the process (usually the "start") to another (usually the "end"), you can see this is a big mess. Both equations are correct provided you understand the definition of the terms.

So here's my goal: I'd like to start using terms that, even if they are not universally used, they do not get used by authoritative sources to mean something completely different!

Immediately that means cycle time is out, because for some (those using equation 1 for example) it means the time between the completion of units (the reciprocal of throughput or delivery rate), and for others it means the time between points in the process.

Lead Time (rather than Throughput Time, another alternative) is the generally preferred term for the time between points in the process in the Kanban community, but this can also be problematic since the natural language use of this term refers to the time between placing an order (as a customer) and receiving the goods. This may include parts of the process which,the designer of a Kanban system has no control over (e.g. agent web sites, queues before entering the system, third party delivery systems, and so on).

We could redefine Lead Time to mean just the time in our system (which suffers from the "other authoritative sources" problem), or - better in my opinion - qualify the term whenever we use it in a formal context: for example System Lead Time; QA Lead Time; Development Lead Time. This means the term is unambiguous (provided the prefixes have been defined for the system) and it also means we can slice the system temporally to view the Little Law effects within subsets of the process.

Term 1 - Lead Time: the time taken for a unit of work to move from one point in the process to another. Used informally to mean either System Lead Time (i.e. the time for a unit to move from the start to end of the system under consideration) or Customer Lead Time (i.e. the time from customer order to customer delivery). Otherwise the term should be qualified to determine the start and end point of the measurement. (Measured in: days, hours, seconds, etc.)

Term 2 - Work In Progress: the number of units of work currently within a specified part of the system or the whole system. Prefer this term to flow units in process or similar.(Measured in: "units".)

Which term should be used for the rate at which units pass through the system or part of the system? Velocity (in Scrum), Delivery Rate and Throughput are all used frequently - probably Delivery Rate is more common in the Kanban community, though I have a slight preference for Throughput. It is only one word, and it applies equally to a subset of the system as to the final delivery part. [Post-publishing Note: The Kanban Leadership Retreat, June 2013 confirmed Delivery Rate as the preferred term.] So...

Term 3 - Delivery Rate: the rate at which units of work pass through the system or part of the system. As with Lead  Time the term may be qualified with a phrase that determines context - e.g. System Delivery Rate or Development Delivery Rate. (Measured in: "units" per day/hour/second.)

So we can now translate the two versions of Little's Law above to preferred terms:

1. System Lead Time = (Work In Progress) / (System Delivery Rate)
2. System Delivery Rate= (Work In Progress) / (System Lead Time)

("System" could be omitted in these equations if the context is clear.)

Finally let's define value-adding time and the 2 efficiency terms for good measure. I'm indebted to Modig and Åhlström's excellent "This is Lean" for these definitions.

Term 4 - Value-adding Time: the total time spent on value-adding activities for one unit of work. Value-adding activities exclude waiting and superfluous work .

Term 5 - Resource Efficiency: a measure of the utilisation of a given resource, i.e. the ratio between the time working on adding value in the system to the total time available.

Term 6 - Flow Efficiency: a measure of time-utilisation on a given unit of work, i.e. the ratio of the Value-adding Time to the (System) Lead Time.

Lean approaches emphasise Flow Efficiency over Resource Efficiency, since maximising Resource Efficiency, so often the first concern of accountants and managers, eventually leads to the traffic-jam state of no flow (see graph above). The efficiency paradox is that the most effective use of resources is achieved at a point where both Resource Efficiency and Flow Efficiency are less than one.

See also: What's the difference between Cycle Time and Lead Time... and why to just use Lead Time in Kanban.