Explanation
What it is
Work In Progress (WIP) Limits define the maximum number of items that can be actively worked on within a workflow stage.
They act as a structural constraint that maintains focus, exposes bottlenecks, and prevents the illusion of progress created by excessive multitasking.
When to use it
- When teams experience frequent context switching or stalled tasks.
- When throughput declines despite high activity levels.
- When bottlenecks or handoffs regularly block downstream flow.
Why it matters
By capping concurrent work, WIP Limits help teams finish tasks faster and improve predictability.
They transform pressure from “do more” into discipline to “finish what’s started,” aligning flow efficiency with sustainable pace.
This shift builds psychological focus, improves delivery quality, and reveals systemic weaknesses that continuous improvement can target.
Reference
Definitions
WIP Limit
A cap on the number of work items that can be in progress at once within a workflow stage or across the entire system.
Flow Efficiency
The ratio of active work time to total elapsed time; a measure of how smoothly items move through the system.
Throughput
The count of completed work items per time unit; used to gauge delivery pace and predictability.
Pull System
A workflow discipline where new work is started only when capacity becomes available, ensuring respect for WIP limits.
Notes & Caveats
- Scope limit
WIP Limits are context-specific; a number that works for one team may choke another. - Common misread
Capping WIP is not about slowing down work — it’s about revealing friction and enforcing focus. - Versioning
Kanban implementations evolve; WIP Limits should be revisited as throughput data matures. - Cultural dependency
Success relies on psychological safety; exposing blockers only works if teams feel empowered to act on them.
How-To
Objective
To establish and calibrate WIP Limits that balance flow efficiency with sustainable team focus, exposing bottlenecks without creating idle capacity.
Steps
- Map the workflow
Visualise every stage of work from intake to delivery using a Kanban board or digital equivalent. - Identify natural bottlenecks
Analyse historical data or observe flow to locate stages that consistently accumulate work. - Set initial limits
Start small: typically 1–2 items per person per stage. Use this as a baseline for experimentation. - Visualise breaches
Highlight columns that exceed their WIP Limit; treat these as improvement signals, not failures. - Facilitate pull discipline
Enforce that new work may only enter a stage when capacity is available downstream. - Review regularly
Revisit limits during retrospectives; increase or decrease based on throughput trends and stress signals. - Document learnings
Capture flow metrics, blockers, and systemic improvements for transparency and future calibration.
Tips
- Begin with team ownership: limits imposed top-down rarely hold.
- Use visual indicators (e.g. colour changes or alerts) to make overload visible in real time.
- Calibrate based on lead time and cycle time metrics to ensure data-driven refinement.
Pitfalls
Treating WIP Limits as static rules
Review and evolve them through retrospectives and metrics.
Using WIP Limits punitively
Frame breaches as learning opportunities, not performance gaps.
Over-optimising for speed
Balance throughput with quality and cognitive load.
Acceptance criteria
- WIP Limits are defined, visible, and collectively owned.
- Breaches trigger discussion rather than blame.
- Throughput and cycle-time metrics show improved predictability over time.
Tutorial
Scenario
A cross-functional product team in a mid-size SaaS company faces constant pressure to deliver features faster.
Their Kanban board shows work scattered across multiple columns, and unfinished tickets pile up near QA.
They decide to apply WIP Limits to improve focus and expose constraints.
Walkthrough
1️⃣ Map the workflow
The team gathers in front of their digital board, mapping every stage from “Ready for Design” to “Done.” They note that “Development” and “QA” are the busiest columns, each with more than ten cards.
Decision Point
Where to draw stage boundaries that reflect real handoffs rather than functional silos.
2️⃣ Identify natural bottlenecks
Using cycle-time data, they confirm QA has the longest average wait. Developers often start new work while old tickets queue for testing.
Input/Output
Input
Jira or Linear reports showing queue age.
Output
Insight that context switching inflates total lead time.
3️⃣ Set initial limits
They agree on a limit of 8 items in Development and 4 in QA, roughly matching available staff and historical throughput.
Action
Add visible WIP counters to each column.
4️⃣ Visualise breaches
A red indicator appears whenever QA exceeds its limit. Within a week, the team spots repeated overloads tied to unclear acceptance criteria.
Error Handling
Instead of ignoring alerts, they introduce a short “definition-check” step before QA intake.
5️⃣ Facilitate pull discipline
Developers now pull new tickets only when QA capacity frees up. At first, idle time feels uncomfortable, but the team learns to use it for refactoring and peer reviews.
Decision Point
Balancing local utilisation versus overall flow.
6️⃣ Review regularly
After two sprints, throughput rises 15 % and lead time drops 20 %. The team lowers the Dev limit to 6 to maintain steady cadence.
Closure
Changes documented in the improvement log; data reviewed during retrospectives.
7️⃣ Document learnings
A Confluence page tracks WIP policies, breaches, and resulting improvements. This record anchors future calibration and onboarding.
Result
- Throughput
18 → 21 stories per month. - Average lead time
12 → 9 days. - Team satisfaction
↑ significantly; meetings focus on flow, not firefighting.
Variations
- Remote teams
Use automation to alert breaches asynchronously. - Service desks
Set WIP Limits per agent queue rather than workflow stage. - Enterprise scale
Aggregate WIP across multiple teams to manage global flow.