What is a WIP limit?
A WIP limit (Work-In-Progress limit) is a cap on how many items can be active at once in a particular column of your workflow — usually "In Progress" or "In Review". When the column is at its limit, no new ticket can enter until something exits.
The rule that follows is simple but powerful: stop starting, start finishing.
Why WIP limits work
- Reduces context-switching — fewer parallel tickets means fewer half-built features and less mental overhead.
- Lowers cycle time — Little's Law says cycle time is proportional to WIP. Half the WIP, roughly half the cycle time.
- Surfaces bottlenecks — if "In Review" hits its limit and stays there, code review is your bottleneck.
- Forces collaboration — when a column is full, the team has to swarm on what's blocked instead of starting something new.
How to set WIP limits
- Per-person rule of thumb — start with 1–2 items per developer in "In Progress".
- Per-column rule of thumb — for a 5-person team, start with WIP=5 on "In Progress" and WIP=3 on "In Review".
- Tighten gradually — drop limits by 1 every few sprints until throughput drops, then back off.
WIP limits in scrum vs kanban
- Kanban — WIP limits are the central practice. Without them, you don't have kanban.
- Scrum — sprint commitment is itself a WIP limit; you can add column-level limits on top to improve flow within a sprint.
Common mistakes
- Setting WIP = team size — too loose; doesn't change behavior.
- Ignoring the limit — if the team adds a 6th item to a WIP=5 column "just this once", the limit dies.
- Limiting only "In Progress" — review and QA are usually the real bottlenecks.