Flow Metrics: Understanding Throughput, Work in Progress and Wait Time

Flow metrics are four measures that show how quickly work moves through a system: throughput, work in progress, cycle time and the age of work already started. They answer questions that utilisation rates and velocity leave open, namely how long an order takes from start to delivery and where it sits in the meantime. Organisations that collect them over a few weeks usually find that most of the cycle time consists of waiting rather than working.

This article explains the measures as defined in the Kanban Guide, shows in a worked example how throughput, work in progress and cycle time relate to one another, and describes how to turn the data into decisions for your delivery organisation. It is written for managing directors and heads of department who want to know why initiatives take longer than planned and who prefer an answer drawn from data to one drawn from impressions.

Which measures make up flow metrics?

Flow metrics consist of work in progress, throughput, cycle time and work item age. The Kanban Guide by John Coleman and Daniel Vacanti, published in 2020, defines them precisely and serves as the primary source for the vocabulary. Work in progress is the number of work items a team has started and not yet finished. Throughput counts the items completed in a period, for example per week. Cycle time measures the span between the start and the finish of a single item, and work item age states how long an item that is still open has already been under way.

Four properties make these measures useful for management. They refer to work items, they can be derived from the timestamps in the ticketing system that already exists, they apply to software teams as much as to procurement or contract review, and they show the effect of decisions within a few weeks. In his 2018 book “Project to Product”, Mik Kersten adds flow efficiency to the picture: the share of active working time in the total cycle time. It shows how much of its time an item is actually being worked on and how much it spends in queues.

How are throughput, work in progress and cycle time related?

The relationship follows Little's Law, a result from queueing theory published by John Little in 1961: the average number of items in a system equals average throughput multiplied by average cycle time. Rearranged, cycle time is work in progress divided by throughput. A team with 24 tasks started and a throughput of six tasks per week has an average cycle time of four weeks. With twelve tasks started and the same throughput, the figure falls to two weeks.

The law holds for systems that run stably over the period observed: on average as much work enters as leaves, and items do not disappear from the system unfinished. The calculation shows the direction in which cycle times move, and it explains why teams with many parallel tasks deliver later. Whether throughput stays the same after work in progress is reduced can only be seen in measurement over several weeks. In practice throughput often holds up, because fewer context switches and fewer handovers free time. How limiting work affects delivery is covered in the article on introducing Kanban.

Where does work lose time in an organisation?

Work loses most of its time at the transitions between roles and departments and at decision points. Work is performed in hours and waited for in days or weeks. Five causes recur. The first is the queue in front of a bottleneck, such as a specialist department that reviews for every business unit. The second is handovers where information is missing and a query sends the order back to the start. The third is the bundling of work into large packages that are released only when the last part is finished. The fourth is dependence on other teams whose priorities differ from one's own. The fifth is simply too much work started at once, so that each item receives only a fraction of attention.

High utilisation aggravates these effects. Queueing theory shows that waiting time in a system with fluctuating arrivals grows disproportionately as utilisation approaches full capacity. A department running at 100 per cent utilisation therefore has no reserve for urgent orders and absences, and every disruption lengthens the queue in front of it. The article on time to market shows where the time between idea and delivery is typically lost.

How do you introduce flow metrics in four steps?

You introduce flow metrics by first defining the start and the end of the work, then analysing the data you already have, examining the distribution and finally deciding on a measure with a review date. The whole path can be completed in four to six weeks without new software.

1. Define start and end: the team agrees on the event from which an item counts as started and when it counts as finished. From the customer's point of view the end is delivery to the user, not the end of development. How precisely this end must be defined is shown in the article on the definition of done.
2. Collect data: for every completed item, the start date and the end date are taken from the ticketing system or a simple spreadsheet. As a rule of thumb, 30 to 50 items are enough for a first analysis, and clean timestamps matter more than a large quantity.
3. Examine the distribution: instead of the average, a scatter plot of cycle times shows how long the faster 50, 85 or 95 per cent of the items took. The work item age of the open items shows which orders have already passed the 85 per cent mark.
4. Decide and review: the team chooses a measure, for example an upper limit on work in progress or a fixed response time for approvals, and checks after four weeks whether the distribution has shifted.

What mistakes occur with flow metrics?

The most frequent mistakes concern the analysis and the use of the figures. The first is the average: a mean cycle time of ten days can hide that individual items take 40 days, and these outliers generate the escalations in management. The second is confusing throughput with velocity. Velocity adds up estimation points that a team assigns itself and that cannot be compared between teams, whereas throughput counts items. The third is comparing teams on their figures, which creates incentives to cut items into pieces or to smooth data. The fourth is measuring only the development part and overlooking the waiting before the start and after completion. The customer, however, experiences the entire span between the request and the delivery.

The figures become more meaningful when leadership uses them as an instrument for improving the system. Management then asks which rule or bottleneck creates the wait. How teams use such measures after a first year with Scrum is shown in the article on Scrum in mid-sized companies.

Flow metrics with Niehues Consulting

Niehues Consulting is a Düsseldorf consultancy for AI management and organisation design from the delivery perspective. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 groups and in more than 20 countries on six continents. Within delivery management he works as delivery manager, project manager or product owner and aligns organisations so that work reaches users without unnecessary waiting.

The approach follows the Niehues Delivery Model with its three phases. Three of its review questions matter most for flow metrics: What is the baseline, and how do we measure success? Which roles, decision paths and interfaces does operation need? Which metric shows after 90 days that the solution is landing? A cycle time with its distribution provides exactly this baseline, and a wait at an interface shows which decision paths need to be reorganised. The entry point is a free initial consultation of 30 minutes, which you can arrange via contact.