A team has ten things in progress. They're all moving forward slowly. Nothing is getting finished. Leadership is frustrated. The temptation is to push harder, add more resources, maybe work longer hours. But the actual problem is too much work in progress.
Work in progress (WIP) limits feel counterintuitive. How can doing less help you deliver more? But the math is unambiguous, and teams that embrace WIP limits consistently outperform those that don't.
The Problem with High WIP
When work in progress is high, several things go wrong:
Context switching destroys productivity. Every task switch has a cognitive cost. Studies suggest it takes 15-25 minutes to fully regain focus after a switch. A person working on three things isn't 33% as productive on each; they're often less than 25% because of the switching overhead.
Nothing finishes. Partial work has zero value until it's done. A team with ten features 50% complete has delivered nothing. A team with five features complete and five not started has delivered five features. The total effort might be identical, but the value delivered is completely different.
Problems hide longer. The longer something stays in progress, the longer before you discover it's blocked, broken, or building the wrong thing. Quick completion creates quick feedback. Slow completion means problems compound.
Coordination costs increase. More things in flight means more dependencies, more handoffs, more communication overhead. The complexity grows non-linearly with WIP.
What Queuing Theory Tells Us
There's actual mathematics behind why high WIP is bad. Queuing theory, developed to understand traffic systems, applies surprisingly well to knowledge work.
The key insight: as utilization approaches 100%, wait time approaches infinity. A highway at 95% capacity moves slowly because any small disruption causes cascading delays. The same is true for engineering teams.
When teams have no slack, everything backs up. A bug that takes someone a day to fix delays everything else by a day. When there's slack in the system, the bug gets fixed while other work continues unaffected.
This is counterintuitive because it seems like 100% utilization should be most efficient. In stable, predictable systems, it might be. In systems with variability, which is all creative work, high utilization creates gridlock.
How WIP Limits Help
Finish before starting. WIP limits create pressure to complete work before starting new work. When the team is at their limit, someone being blocked should trigger collaboration to unblock them, not starting something new.
Expose bottlenecks. When WIP is unlimited, bottlenecks are invisible because work accumulates without anyone noticing. WIP limits make blocked work visible: "We can't start anything new because these three things are stuck in review." Now you know where to focus improvement.
Reduce context switching. With limits on how many things can be in progress, people work on fewer things at once. Less switching, more focus, faster completion.
Create flow. WIP limits smooth the flow of work through the system. Instead of bursts of starting followed by nothing finishing, work moves more steadily from start to done. This aligns with broader lean engineering principles.
Setting Effective Limits
How do you choose the right WIP limit? There's no universal answer, but some guidelines:
Start higher than you think, then lower. If a limit is too high, it won't change behavior. If it's too low, work grinds to a halt. Start conservative and tighten until you feel resistance, then back off slightly.
Per-column limits often work better than total limits. Limits on each stage of your workflow (development, review, testing) expose stage-specific bottlenecks. A single total limit hides where work is stuck.
Consider work size. A limit of three makes sense if each item takes a few days. It doesn't make sense if items take an hour. Match limits to the granularity of your work.
Account for blocking. If work frequently gets blocked waiting for external dependencies, you might need slightly higher limits to keep people productive while waiting. But better yet, fix the blocking.
Common Objections
"We can't limit WIP because priorities change." If priorities change constantly, you have a prioritization problem, not a WIP problem. Limiting WIP doesn't prevent reprioritization; it makes the cost of reprioritization visible. If you drop something in progress to start something new, you've spent effort that won't deliver value.
"Our team is blocked too often to have low WIP." That's the point. WIP limits make blocking visible and painful. This creates pressure to reduce blocking, which is the actual improvement you need.
"People will be idle." First, this is often exaggerated. Second, occasional idle time is better than constant context-switching. Third, idle time can be used productively: helping teammates, reducing technical debt, learning. The goal is maximizing flow, not maximizing busy-ness.
"This doesn't work for our team." Maybe. But more often, this is resistance to change disguised as uniqueness. Try it as an experiment. If it genuinely doesn't work, you'll learn why. If it does work, you'll deliver more.
Making It Work
WIP limits only work if they're real constraints, not suggestions:
Make limits visible. Everyone should know what the limits are and current WIP levels. Kanban boards work well for this.
Enforce them. When you hit the limit, you can't start new work. This is the whole point. If you make exceptions routinely, you don't actually have WIP limits.
Discuss violations. When people want to exceed limits, discuss why. Sometimes the limit should change. Usually it's pressure to start things rather than finish them. These conversations are valuable.
Review and adjust. WIP limits should evolve as the team and work change. What's right today might not be right next quarter. Build in periodic review.
WIP limits are one of the highest-leverage changes a team can make. They're free to implement, they expose real problems, and they consistently improve delivery. The only cost is accepting that finishing things matters more than starting things.
Frequently Asked Questions
Want help implementing WIP limits and improving team flow?
Let's Talk →