WIP Limits: How to Set and Enforce Work-in-Progress Limits
Understand Work-in-Progress limits, why they matter, and how to calculate the right WIP limit for your team. Includes examples and formulas.
Best Practices
Detailed Explanation
Work-in-Progress (WIP) Limits
WIP limits are the single most impactful practice in Kanban. They cap the number of items allowed in a column at any given time, preventing overload and forcing the team to finish work before starting new tasks.
Why WIP Limits Matter
Without WIP limits, teams tend to start many items but finish few. This leads to:
- Long cycle times -- items languish in progress for days or weeks.
- Context switching -- developers juggle multiple tasks, reducing efficiency by 20-40%.
- Hidden bottlenecks -- overloaded columns mask the real constraint.
How to Calculate WIP Limits
A common starting formula:
WIP Limit = Number of team members x 1.5
For a team of 4 developers, start with a WIP limit of 6 for the Development column. Adjust based on observation:
- If the column is always at capacity and cards wait to enter, lower the limit.
- If the column is rarely full and downstream is starved, raise the limit.
Column-by-Column Guidelines
| Column | Suggested WIP | Rationale |
|---|---|---|
| Backlog | No limit | This is a holding area |
| Ready | 5-10 | Enough runway without excessive pre-planning |
| Development | Team size x 1.5 | Core working column |
| Code Review | Team size x 0.5 | Reviews should be fast |
| QA | 3-5 | Testing should not accumulate |
| Done | No limit | Completed work |
Enforcing WIP Limits
- Make limits visible on the board (e.g., "Development [3/4]").
- When a column hits its limit, the team must swarm on existing items instead of pulling new work.
- Discuss WIP violations in retrospectives, not as punishment but as learning opportunities.
Use Case
Use this guide when establishing or refining WIP limits for a Kanban board. It is especially useful during team onboarding or process improvement retrospectives.