The One Equation That Explains Most Delivery Slowdowns

Delivery slows down. The natural response is to start more work — more tracks, more initiatives, more items in progress. This is the mistake that makes it worse.

It is not a rare mistake. It is the standard response in most organisations facing delivery pressure. Start more things in parallel. Show the board that you are moving. Keep everyone occupied. The result is a system carrying more items through the same queues, completing fewer of them on time, and accumulating the kind of aging WIP that only shows up in cycle time data most teams aren't tracking.

The response that backfires

The logic behind starting more work seems sound. If you have twelve engineers and twelve things to do, starting all twelve simultaneously means they all make progress. Waiting in sequence means half the team is idle. Parallelism is efficient.

This is true for independent resources working on fully separable tasks. Software delivery is neither of those things. Work depends on review. Review depends on capacity. Capacity is shared. When twelve items enter a system simultaneously, they do not each get one engineer's undivided attention. They each get a fraction of several engineers' divided attention, plus a position in every downstream queue.

More starts do not produce more completions. They produce more waiting.

Three numbers that explain the whole thing

Software delivery systems — like any queueing system — have three fundamental variables that describe how they behave.

Work in progress is the count of items that have started but not finished. It is not a measure of effort or value. It is simply the number of things the system is currently handling. Throughput is the count of items completing per unit of time — typically per week. It is what the system actually delivers. Cycle time is the elapsed time from when an item starts to when it finishes. It is what the customer experiences.

These three variables are not independent. They are connected by a mathematical relationship that holds across every queueing system from hospital queues to highway traffic to software teams.

The relationship

Average cycle time equals average WIP divided by average throughput.

This is not a heuristic developed from experience. It is a mathematical property of stable queueing systems, established in operations research decades ago. It holds regardless of the technology, the team size, or the methodology in use.

The implication is direct. If throughput stays constant — if the team is completing the same number of items per week — and WIP increases, cycle time increases proportionally. More work in the system means each item waits longer. The system did not slow down because people worked less. It slowed down because more items were competing for the same capacity.

The worked example

Consider a team completing four items per week with twenty items currently in progress. The equation gives an average cycle time of five weeks. That is how long a typical item is spending in the system from start to done.

Reduce WIP to twelve — by stopping new starts until old work is finished — with throughput unchanged. Average cycle time drops to three weeks. A 40% improvement from a policy change that costs nothing, requires no new tooling, and takes effect within weeks.

Now consider the reverse. The same team, completing six items per week, carrying thirty items in progress. Leadership decides to start twelve additional initiatives without adding capacity. Average cycle time before: five weeks. Average cycle time after: seven weeks. The system just got 40% slower because more work entered it than it can absorb.

Nobody changed the process. Nobody made a bad decision about technology. Nobody reduced effort. The simple act of adding items to the system — without a corresponding increase in throughput — made everything slower.

The direction managers always get wrong

When cycle time is too long, the standard response is to add initiatives, pressure, or people. Each of these is likely to make the problem worse unless throughput increases in proportion to WIP.

Adding initiatives without adding throughput increases WIP. Adding pressure without addressing queue constraints does not reliably increase throughput. Adding people takes time to produce throughput and immediately increases coordination overhead. Meanwhile, the queue grows.

The first lever to examine is always WIP — not because it is always sufficient, but because it is the only lever where the direction of causality is unambiguous and the cost of the intervention is zero.

WIP is the lever you control

Throughput is an output of the system. It depends on complexity, review capacity, dependency chains, testing environments, and dozens of other variables that resist direct manipulation. You cannot decide to have higher throughput this week. You can decide how many items to allow in progress.

WIP is a policy. The answer to "how much WIP do we have?" is "however much we have chosen to allow." Most teams have not made this choice explicitly — WIP has grown organically, one item at a time, as each person picks up whatever is next. Making the choice explicit, and setting a limit, is the fastest and cheapest intervention available.

What this means for prioritisation

Starting everything at once is not parallel progress. It is deferred completion. Each item entering the system takes a position in every queue it will eventually pass through. Ten items at fifty percent complete are worth less than five items finished — because finished items have delivered their value, cleared their queue positions, and freed capacity for what comes next.

One item finished is worth more than ten items at 50%. Finishing is how value gets delivered. Starting is how queues get longer.

The shift in practice is simple to state and politically difficult to execute. Limit what is allowed to start. Finish what is in flight before adding more. Use the equation as a diagnostic: if cycle time is unacceptably long, the first question is always what WIP is doing.

Count your current WIP. Divide by your average completions per week. The result is approximately how long a new item starting today will spend in the system before it finishes. If that number does not match the delivery speed your stakeholders are expecting, you now know where to look first.