Library→First Way: Flow→Concepts→WIP Limits and Queue Theory
WIP Limits and Queue Theory
How limiting work in progress speeds up delivery. Little's Law, queue dynamics, and why starting less means finishing more.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
The multitasking illusion
Most software teams have more work in progress than they can handle. Developers juggle 3-5 tasks. Reviewers have 10 open PRs. QA has 20 tickets in progress. The intuition is that more concurrent work means more throughput. The data says the opposite.
Context switching between tasks has a real cost. Gerald Weinberg found that switching between 2 projects costs each project 20% overhead. Three projects: 40%. Five projects: 75%. The more things in progress simultaneously, the less effectively each one is being worked on.
Stop starting. Start finishing. The goal is not to keep everyone busy — it is to keep work moving. A team where everyone is busy but nothing ships has a WIP problem.
Little's Law
John Little's theorem (1961) describes the relationship between work in progress, throughput, and lead time in any stable system. It is one of the most important equations in operations research — and it applies directly to software delivery.
Little's Law
L = λ × W
L
Items in system (WIP)
λ
Arrival rate (throughput)
W
Time in system (lead time)
High WIP
WIP = 20 items
Throughput = 2 items/day
Lead Time = 10 days
Low WIP (same throughput)
WIP = 5 items
Throughput = 2 items/day
Lead Time = 2.5 days
Reducing WIP from 20 to 5 with the same throughput cuts lead time by 75% — without adding any capacity.
The key insight: to reduce lead time without adding capacity, reduce WIP. You do not need to hire more people or work faster. You need to have fewer things in flight at the same time.
WIP limits in practice
A WIP limit is a constraint on the number of items that can be in a given stage of the workflow at the same time. When a stage is at its WIP limit, no new work can enter until an item exits. This forces the team to focus on finishing before starting.
When a WIP limit is hit, the right response is not to bypass it — it is to swarm on the blocked work. If Review is at its limit of 2, the entire team should focus on getting those 2 items through review before starting anything new.
Queue dynamics
Queues are expensive. Work sitting in a queue is not just idle — it is accumulating holding costs: delayed feedback, growing merge conflicts, stale context, and opportunity cost.
Queue theory shows that as utilization approaches 100%, queue length grows exponentially, not linearly. A team at 80% utilization has manageable queues. At 95% utilization, queues explode. This is why always-busy teams deliver slowly: they have no slack to absorb variability, so everything queues behind the next bottleneck.
80%
utilization
Wait time: 4x service time
Manageable
90%
utilization
Wait time: 9x service time
Strained
95%
utilization
Wait time: 19x service time
Broken
How to set WIP limits
There is no universal formula. Start by making WIP visible, then lower the limit until it causes productive tension — the team must collaborate to unblock items rather than starting new work.
- 1
Count your current WIP
How many items are in each stage right now? Most teams are surprised by the number. This is your baseline.
- 2
Set limits slightly below current
Start with a limit of team size minus one. Adjust based on what you observe.
- 3
Enforce the limit visibly
When a column is full, the team stops and helps move items through. The limit is the forcing function.
- 4
Measure lead time
As WIP decreases, lead time should decrease. Track it. If it does not, the constraint is elsewhere.
Further reading
Kanban — David Anderson
The definitive guide to WIP limits and Kanban in software development. Chapter 4: WIP Limits.
Principles of Product Development Flow — Reinertsen
The mathematical foundation of queue theory applied to product development. Dense but essential.
Making Work Visible — Dominica DeGrandis
Practical guide to identifying and exposing time theft and WIP problems in software teams.
DevOps Handbook
Chapter 8: How to Enable and Practice Continuous Integration. WIP limits in CI/CD pipelines.