Skip to main content

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.

Post a Comment

Popular posts from this blog

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…

"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…

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…