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.