The throughput argument: interpreting flow data before reverting a limit
A nine-person team has six months of flow data. Throughput averages 24 items a month. Average WIP across the three working columns is 31. Average lead time, measured from the moment a card enters the unlimited Ready column, is 39 working days (p50 34, p85 62, p95 96). Flow efficiency sampled on 20 items is 22%. Blocked time is roughly 35% of lead time, and 80% of that blocked time comes from one dependency: a compliance review with no queue, no owner and no due-date policy. Four weeks ago the team cut the In Progress limit from 18 to 11, taking total working WIP from about 40 to 25. Throughput fell to 19 items a month and p50 lead time fell to 29 days, but p85 is 58 and p95 is 88. Two developers want the old limit back because 'the limit is costing us throughput'.
1. Reconcile the numbers using Little's law. What explains the gap, and what should be fixed about the measurement?
Read the worked answer
Using 21 working days a month: 24 items a month is about 1.14 items a day. Little's law says average lead time equals average WIP divided by throughput, so 31 divided by 1.14 gives roughly 27 working days - against a measured average of 39. A 12-day gap is too large to be noise.
The explanation is a boundary mismatch. Lead time starts when a card enters the unlimited Ready column, but WIP is counted only across the three working columns. Little's law is robust, but only when the WIP count covers exactly the scope the lead time measures. Ready holds a large population of cards - roughly 12 days' worth at this throughput, about 13 items - that is inside the lead-time clock and outside the WIP count. The system's largest queue is therefore invisible in its own metric.
Two fixes, either of which is legitimate: start lead time when a card enters In Progress, or count Ready in the WIP. The second is better here, because Ready is where the delay actually happens and hiding it invites the team to optimise the wrong end of the flow. Take the WIP average consistently at the same time each day, and state the measurement boundary on the board so nobody re-derives a different number later. After that, if Little's law still fails, look for items that leave and re-enter, split or merged items, and throughput counted at a different point from the one where WIP is counted.
2. Should the team restore the old limit? Argue from the data, including what the tail is telling you.
Read the worked answer
No - but the developers' observation deserves a proper answer rather than a dismissal.
Check the post-change arithmetic: 19 items a month is about 0.9 a day; 25 divided by 0.9 gives roughly 27.6 working days average, statistically indistinguishable from the 27 days before the change. So average lead time has barely moved, which is consistent with p50 improving modestly from 34 to 29. The real movement is in the tail: p85 from 62 to 58 and p95 from 96 to 88. That is what reducing WIP does in a blocked system - it compresses the worst cases first, because the items that used to sit behind a crowd of half-finished work now start sooner relative to their finish.
The throughput drop from 24 to 19 has three plausible causes, none of which argues for reverting: upstream starvation, because the unlimited Ready column was previously feeding a wide In Progress and readiness is now the constraint; reduced batching, which lowers measured item count while leaving value unchanged; and measurement lag, since throughput is counted at delivery. Four weeks is too short to judge, and reverting restores the concurrency that produced 96-day worst cases - the very number that breaks the team's promises. Set a review date, keep the limit, and go after the constraint.
3. What is the next improvement experiment, and what would convince you it worked?
Read the worked answer
Attack the dependency that owns 80% of blocked time: the compliance review.
Hypothesis. If compliance review runs to a fixed twice-weekly slot with a WIP-limited intake and a written definition of ready, blocked time falls from 35% to under 20% of lead time within eight weeks, and p85 lead time falls below 45 days without raising WIP.
Why this and not something else. Blocked work is the cheapest throughput available in this system. At constant WIP, cutting lead time raises throughput by Little's law - that is the route back to 24 items a month without restoring the old limit and its 96-day tail. Flow efficiency of 22% says four-fifths of the elapsed time is waiting, so the leverage is in the waiting, not in working faster.
Measures. Weekly: blocked time share, average blocker age by dependency, number of items in the compliance queue. Monthly: p50, p85 and p95 lead time, throughput, flow efficiency. Keep the current limit fixed for the duration so the experiment has one variable.
Cadence and decision rule. Review weekly at standup for leading indicators, and at the monthly operations review for the distribution. Pre-agree the reversal criterion: if after eight weeks blocked time is above 30% and p85 has not moved, the constraint is elsewhere - most likely readiness upstream - and the next experiment moves there. Do not re-baseline the lead-time target mid-experiment; that is how improvement programmes lose credibility.