WIP limits in Kanban are one of the most powerful and most counterintuitive practices in Agile and Lean delivery management. WIP — Work in Progress — refers to the number of work items currently active in a given stage of the workflow. A WIP limit is a maximum cap on how many items can be in a specific column of the Kanban board at any time. When a column reaches its WIP limit, no new work can enter that column until an existing item exits — forcing the team to finish what it has started before starting something new. This apparently simple constraint consistently produces dramatic improvements in delivery speed, quality, and predictability, even when it initially feels like slowing down. This guide explains the theory and practice of WIP limits for project managers.
Why WIP Limits Work: The Mathematical Foundation
WIP limits work because of Little’s Law — the mathematical relationship between WIP, throughput, and cycle time in any stable queuing system: Cycle Time = WIP ÷ Throughput. If throughput (the rate at which the team completes work) remains relatively stable, then cycle time is directly proportional to WIP. Halving WIP halves cycle time. Doubling WIP doubles cycle time. This is not a management opinion or a hypothesis — it is a mathematical theorem that applies to any stable queuing system.
The practical implication is profound and counterintuitive: starting fewer things simultaneously makes each individual thing finish faster. A team with 20 items in progress completes each item more slowly than a team with 10 items in progress at the same throughput rate, because each item must wait longer for attention in a larger queue. WIP limits mechanically enforce the stop-starting, start-finishing discipline that transforms a multitasking team into a focused, flow-optimised delivery system.
How WIP Limits Expose Bottlenecks
One of WIP limits’ most valuable — and initially surprising — effects is making bottlenecks visible. In a Kanban system without WIP limits, work accumulates invisibly in front of bottlenecks: the “In Testing” column might silently hold 15 items while the team continues to push new items into “In Development.” The WIP limit prevents this silent accumulation. When the “In Testing” column hits its WIP limit, the Development team cannot move more items into Testing — they are forced to stop and either help with testing or wait. This forced pause makes the bottleneck visible and creates immediate organisational pressure to address the capacity constraint causing it. In this way, WIP limits function as a real-time bottleneck detection system: the first column to repeatedly hit its limit is the system’s current constraint.
Setting Initial WIP Limits
A common question for teams implementing WIP limits is where to start. The widely recommended starting point is n+1, where n is the number of people who work in that stage — one more than team size. This provides enough capacity for continuous flow (the extra slot prevents the stage from being starved when one person finishes) while creating enough constraint to drive focus (the limit prevents unlimited multitasking). Starting with n+1 is not optimal — it is a safe, empirically-adjustable starting point that prevents the paralysis of trying to calculate the perfect limit mathematically before you have flow data to inform the decision.
After implementing initial limits, observe the system for 2–4 sprints. Which columns consistently hit their limits? Which are never close to their limits? Use this data to adjust: lower the limits for columns that never approach them (to create more focus), investigate and address the constraints causing the columns that are always at their limit. The goal is a set of WIP limits that creates enough constraint to prevent multitasking while not creating so much constraint that work is perpetually blocked.
“Stop starting, start finishing. WIP limits are the structural enforcement of this principle — they make the right behaviour (finishing before starting) the path of least resistance.” — David Anderson, Kanban: Successful Evolutionary Change
WIP Limits vs Sprint Commitment
WIP limits and sprint commitment are both tools for managing team focus, but they operate differently. Sprint commitment sets a fixed quantity of work for a time-boxed period — the team commits to completing a defined set of stories within the sprint. WIP limits regulate the flow of work through the system continuously — they cap how many items can be active at any stage at any moment, regardless of sprint boundaries. Kanban teams use WIP limits as their primary focus mechanism; Scrum teams use sprint commitments. Scrumban teams — combining Scrum’s cadences with Kanban’s WIP limits — use both, with WIP limits managing flow within the sprint and sprint commitments managing the overall sprint scope.
WIP Limits Implementation Guide
| Stage | Starting WIP Limit | Adjust Down If | Adjust Up If |
|---|---|---|---|
| In Development | Developers + 1 | Rarely hits limit | Always blocked; downstream starved |
| In Code Review | Reviewers + 1 | Items never queue here | Frequent blocker creating idle devs |
| In Testing | Testers + 1 | Always empty; testers idle | Backlog constantly overflows |
| Ready for Deploy | 3–5 items | Items linger here for days | Deploy pipeline is the bottleneck |
Managing Difficult Vendor Relationships
Even well-structured vendor relationships encounter periods of underperformance, conflict, or misaligned expectations. Project managers who handle these situations effectively prevent minor issues from escalating into contract disputes or delivery crises. Key principles for managing difficult vendor situations include: addressing performance concerns immediately in writing rather than allowing them to compound; framing performance conversations as problem-solving sessions (“how do we resolve this together?”) rather than blame assignments; escalating to the vendor’s senior management when working-level discussions fail to produce change; and ensuring that all commitments made in resolution discussions are confirmed in writing within 24 hours. When underperformance is persistent and severe, the contractual remedies available — service credits, termination for cause, performance improvement plans — should be exercised based on documented evidence, not emotional frustration. The quality of your written performance record determines the strength of your contractual position if formal remedies are needed.
Key Takeaways
- WIP limits work because of Little’s Law — cycle time is directly proportional to WIP when throughput is stable; halving WIP halves cycle time.
- The counterintuitive truth: starting fewer things simultaneously makes each thing finish faster — WIP limits enforce the stop-starting, start-finishing discipline that flow-optimised teams require.
- WIP limits expose bottlenecks by preventing silent queue accumulation — the first column to consistently hit its limit is the system’s current constraint.
- Start with n+1 (team size + 1) as the initial WIP limit for each stage, then adjust empirically based on 2–4 sprints of observed flow data.
- WIP limits that never trigger provide no benefit — if a column never approaches its limit, lower it until it creates some constraint and drives focus.
- Combine WIP limits with a visible Kanban board and regular flow metrics review (cycle time, throughput, cumulative flow diagram) for a complete flow management system.
