Where the time actually goes

Why is most of the time a piece of work takes not spent working on it?

Ask a team how long a small change takes and you will hear something like a day. Then measure the same change from the moment it was requested to the moment it was in front of a user, and the answer is three weeks.

The obvious explanation is that the estimate was optimistic — everyone knows engineers underestimate. But that reading is worth resisting, because it may be wrong in an interesting way. Suppose the day was accurate. Suppose someone really did spend about a day of hands-on effort on it. Where did the other fourteen working days go, and why does nobody remember losing them?

Take the change apart into its intervals. Requested, then sitting in a backlog. Picked up, worked on. Pushed, then waiting for review. Reviewed, then waiting for a build slot. Built, then waiting for a test environment. Passed, then waiting for the release window. Released.

Now sort those intervals into two kinds: intervals where somebody is doing something to the item, and intervals where the item is sitting still. The first kind is the day. The second kind is everything else. And notice something about the second kind — nobody experiences it as time spent, because during it every person involved is busy with a different item. The waiting is invisible from every individual vantage point, and visible only from the item's.

That is the first real insight: the time an item takes is dominated by intervals nobody is aware of. Which means asking people to work faster addresses the smallest term in the sum.

Now the harder question — why is waiting so large? Here queueing theory gives a genuinely non-obvious answer. For a system with variable arrivals and variable service times, the average time in the queue rises with utilisation, and the rise is not linear: as a resource approaches being fully busy, waiting grows without bound. A specialist who is 50% busy is roughly a one-queue-length wait; the same specialist at 90% busy makes the wait many times longer, though the work itself has not changed at all.

Sit with that, because it inverts a strong intuition. Keeping everyone fully occupied looks like efficiency, and locally it is — each person's output is maximised. But full occupancy is exactly the condition that makes the queues in front of them explode, and total lead time is mostly queue. High utilisation and short lead time are in direct tension, and an organisation that optimises for the first has chosen against the second, usually without noticing it made a choice.

There is a second driver: variability. Two systems with identical average utilisation but different spread in arrival timing or task size will not wait the same. Bursty arrivals and wildly uneven task sizes both inflate the queue — which is one honest reason to break large items down, not because small items are worked faster but because they smooth the flow they travel through.

And a third: handoffs. Every transfer between people is a place where an item can stop, and six stages with a modest queue each produce a long total by simple addition.

So what should be measured? If waiting dominates, throughput and individual output tell you almost nothing about speed. What reveals the structure is the elapsed time from request to done, and its decomposition: what fraction of it was active. That ratio has a name, flow efficiency, and the claim usually attached to it is that in knowledge work it is startlingly low — often reported somewhere between a few percent and fifteen. Treat any specific figure as indicative rather than measured for your team; the reason to measure your own is precisely that it tends to come in far below what anyone expects.

Three refinements.

First, distinguish the two measurements that get muddled. Lead time is measured from the customer's request; cycle time is usually measured from when work actually begins. Teams that report the second and call it the first exclude the largest queue in the system — the backlog — and produce a comfortable number that no customer would recognise.

Second, none of this says waiting is waste to be eliminated to zero. Some waiting buys real things: batching a release reduces the risk of each change, a review queue exists because reviews are valuable, slack in a schedule is what absorbs urgent work. The claim is narrower and more useful: waiting is where the time goes, it is currently unmeasured, and unmeasured time cannot be traded off deliberately.

Third, there is a relationship worth knowing because it makes the lever concrete. Little's Law says that in a stable system, the average number of items in progress equals the average arrival rate multiplied by the average time each item spends in the system. Rearranged: average lead time equals work in progress divided by throughput. Since throughput is bounded by capacity and hard to raise quickly, the fastest way to shorten lead time is to reduce how many things are in flight at once — which is why limiting work in progress is the standard intervention. Starting less is how you finish sooner, which is counter-intuitive until you have seen where the time goes.

• Little's Law applied to a real board, and what work-in-progress limits do to a team's queues in practice.
• Why utilisation targets and lead-time targets cannot both be maximised.
• Measuring flow efficiency honestly, including how to date the start of an item's wait.

Every term the collection defines is gathered in the glossary.