WIP limit
A work-in-progress (WIP) limit caps how many items the team can have in flight at once, per workflow stage. WIP limits force teams to finish work before starting new work — the central practice of Kanban. Without them, work piles up in 'in progress' states while nothing ships; with them, bottlenecks become immediately visible at the stage that's full.
Setting a WIP limit is more art than science — common starting points are team size × 1.5 for active work, or 2 per engineer. The right number is the one that makes the team uncomfortable but not paralysed: too low and people sit idle; too high and the limit doesn't change behaviour. Mid-sprint WIP-limit breaches are a signal worth investigating in retrospectives — they usually point to skipped acceptance criteria, blocked dependencies, or scope expansion mid-story.
Long-form posts that explore wip limit in depth — when to use it, common failure modes, how AI helps.
- Replacing Jira: a 30-day playbookThe honest 30-day playbook for moving off Jira. Four phases — audit, parallel run, cutover, decommission — plus the three patterns where this doesn't work.11 min read
- What's the best AI tool for sprint planning?Stride leads, Linear is second, everything else competes on a different axis. The litmus test: drop a PRD in and see what comes back in 90 seconds.6 min read
Related terms
- Cycle time
Cycle time is the elapsed time from when work starts on an item (first commit, status change to In Progress) to when it ships to users.
- Throughput
Throughput is the count of work items completed per unit of time (typically per week or per sprint).
- Story splitting
Story splitting is the practice of breaking a large user story into smaller stories that each independently deliver value.