Work in Progress Limits
The counterintuitive practice that improves everything.
1Why Limit WIP?
WIP limits are constraints on how many items can be in progress at a given stage—or across the whole system—at once.
This seems wrong. Shouldn't we work on as much as possible? Isn't more activity better?
No. And here's why:
Little's Law: Lead Time = WIP / Throughput
If throughput is constant, cutting WIP in half cuts lead time in half. This is mathematics, not opinion.
Context switching: Every additional item in progress fragments attention. With 1 item, you have 100% focus. With 5 items, you have 20% focus on each. Context switching between them burns the rest.
Queue formation: High WIP means items wait in queues. Low WIP means items flow through faster.
Finish before starting: With WIP limits, you must finish something before starting something new. This forces completion.
The counterintuitive result: doing less at once means finishing more overall.
The Stop Starting Mantra
Stop starting, start finishing. It sounds like a slogan, but it's the core principle. Every 'started' item that's not finished is inventory. Every item you don't start is one fewer queue entry, one less context switch, one more focus unit available.
2Setting Initial WIP Limits
How do you know what WIP limit to set?
Start with observation: Count how many items are in progress right now. If you have 20 items across 5 people, that's your baseline.
Cut it in half: Seriously. Most teams have far too much WIP. Cutting it in half is usually a good starting point.
Per-stage vs. system-wide: You can set limits per stage (e.g., max 3 items in Code Review) or system-wide (e.g., max 10 items across all stages). Start with what's simpler for your team.
One per person plus buffer: A common starting point is n+2 where n is team size. So a team of 4 might start with WIP limit of 6.
Adjust based on results: WIP limits should be tight enough to create flow but not so tight that people have nothing to work on. If the limit is never hit, it's too high. If people are constantly idle, it might be too low.
The goal isn't to find the "perfect" WIP limit—it's to create a forcing function that drives completion and surfaces problems.
Team of 5 had average 18 items in progress. They set WIP limit of 9. First sprint felt slow. Second sprint, lead time dropped from 3 weeks to 8 days. Third sprint, they lowered to 7. Lead time dropped to 5 days.
Team sets WIP limit of 30 for a team of 5. The limit is never hit. Nothing changes. WIP accumulates to 25-28 without triggering any action. The limit is decorative, not functional.
3When You Hit the Limit
WIP limits only work if you respond when you hit them. What do you do when the limit is reached?
Swarm: Stop what you're doing and help clear the bottleneck. If Code Review is at its limit, developers help review instead of writing new code.
Wait productively: If you can't start new feature work, do improvement work: pay down tech debt, write tests, automate a painful process.
Escalate blocks: If the limit is hit because something is blocked, escalate immediately. The block can't hide.
Analyze: Why is the limit being hit? Is this stage the constraint? Is there a systemic issue?
What you should NOT do:
- Ignore the limit ("just this once")
- Raise the limit to avoid the conversation
- Start work "off the board"
- Count items differently to game the number
The limit is there to create pressure. Pressure surfaces problems. Problems, addressed, lead to improvement.
Violating the Limit = Signal
When you're tempted to violate the WIP limit, that's a signal. Something is wrong—either the limit is genuinely too low (rare) or the system has a problem worth discussing (common). Use the temptation as a trigger for improvement.
- Little's Law: reducing WIP reduces lead time proportionally
- WIP limits force completion and surface bottlenecks
- Start by cutting current WIP in half
- When limits hit, swarm or do improvement work
- Never violate limits silently—the pressure is the point