Why a fully booked engineering team ships slower.
Queueing theory explains why keeping every developer busy stretches lead times, and how planning capacity and limiting work in progress speeds delivery.
Published · 7 min read
When a software team is late, the instinctive response is to make sure everyone is busy. Fill every sprint, start the next project before the current one ends, keep the backlog of each developer full. It feels efficient. It is also one of the most reliable ways to make delivery slower, and the reason is not motivation or skill. It is mathematics that factories and telecom networks learned decades ago.
Work waits in queues
A request that reaches a team rarely gets worked on right away. It waits for someone to be free, then waits again for a review, a test environment, a decision or a deployment slot. In most teams, the time a piece of work spends waiting is much longer than the time anyone spends working on it.
Queueing theory describes how those waits behave. Its central result is simple to state: as a resource gets close to full utilization, the waiting time in front of it does not grow steadily. It grows explosively.
| Team utilization | Wait |
|---|---|
| 5% | 0 × |
| 10% | 0 × |
| 15% | 0 × |
| 20% | 0 × |
| 25% | 0 × |
| 30% | 0 × |
| 35% | 1 × |
| 40% | 1 × |
| 45% | 1 × |
| 50% | 1 × |
| 55% | 1 × |
| 60% | 1 × |
| 65% | 2 × |
| 70% | 2 × |
| 75% | 3 × |
| 80% | 4 × |
| 85% | 6 × |
| 90% | 9 × |
| 95% | 19 × |
In the simplest model, a team at 50% utilization makes work wait, on average, about as long as the work itself takes. At 80%, the wait is four times the work. At 90%, nine times. At 95%, nineteen times. The last few points of "efficiency" are paid for with weeks of delay.
This is why a team that looks fully productive can still feel slow to everyone around it. Each person is busy, and each piece of work is mostly sitting still.
Uneven work makes it worse
The curve above assumes a moderate amount of randomness. Software work is often more uneven than that: some tasks take an hour and others take two weeks, and urgent requests arrive without warning. Kingman's formula, a standard approximation in queueing theory, shows that waiting time scales with this variability as well as with load.
At the same 85% utilization, a team with steady, similar-sized work waits about half as long as the reference case. A team flooded with urgent interruptions and very uneven tasks waits about twice as long. The two levers multiply each other: high load with high variability is where delivery stalls.
Less in progress, faster delivery
Little's law, a result that holds for almost any stable system, links three numbers: average lead time equals work in progress divided by throughput. If a team finishes ten items a week and has forty items open, each item takes four weeks on average from start to finish.
The useful consequence is that a team can shorten its lead times without working any faster. Starting less work at once is enough. Throughput stays the same, but each item spends less time waiting behind the others, and feedback on it arrives sooner.
Less work in progress also brings benefits that do not appear in the formula. People switch context less often, problems surface while the work is still fresh, and finished features start delivering value earlier.
What this means for planning
None of this argues for idle teams. It argues for planning with the curve in mind.
- Plan for 70 to 80% of capacity. The remaining time absorbs urgent fixes, reviews and the unexpected without stalling everything else. Teams that plan for 100% are already late on the first day.
- Limit work in progress. Set a cap on how many items can be in progress at once, per team or per stage, and finish work before starting more. A board with fewer cards in progress usually moves faster.
- Reduce variability where you can. Split large items into small, similar-sized ones. Route urgent requests through a dedicated, limited channel instead of letting them interrupt everything.
- Watch the queues, not the people. Measure how long work waits for review, testing and deployment. The longest wait is usually the cheapest place to gain speed, and automation such as continuous integration and one-click deployment removes several queues at once.
A note on the models
These figures come from standard models with simplifying assumptions, not from measurements of a particular team. Real teams are messier. The shape, though, is robust: waiting grows sharply with load, grows with variability, and falls when less work is in progress. Teams that measure their own lead times almost always find the same pattern.
Where to start
Measure two numbers for a month: how many items your team finishes per week, and how many are in progress on an average day. Divide the second by the first and compare the result with how long work actually takes to reach users. If the numbers surprise you, we can help you find where work waits. Our software engineering services include setting up the delivery pipelines that remove those queues.