By: WKFGo Editorial · ·
What is a Kanban WIP limit?
A work-in-progress limit caps how many items may occupy a workflow state at one time. A Review limit of three means the team should not pull a fourth item into Review until capacity becomes available or the team explicitly handles the exception.
The purpose is not to keep every person busy. It is to reduce context switching, expose constrained stages, and move work to completion. A limit without a pull policy is only a number painted above a column.
Why limiting work can increase delivery
When a team starts more work than it can finish, queues grow. Every queued item waits, ages, and risks becoming stale. People switch contexts, reviewers receive large batches, and stakeholders see many “almost done” cards but little delivered value.
Little's Law describes the relationship in a stable system:
Work in progress = throughput × average cycle time
It is not a promise that lowering WIP automatically fixes delivery. Arrival rate, workflow quality, item size, and capacity still matter. But if throughput stays roughly stable, uncontrolled WIP tends to increase cycle time.
Where to place limits
Start with workflow states where active work or a queue consumes scarce capacity:
| State | What the limit protects | Example signal |
|---|---|---|
| In Progress | focus of makers | people switch tasks repeatedly |
| Code Review | reviewer capacity | PRs wait longer than coding took |
| Testing | test environment or QA | completed development arrives in batches |
| Approval | specialist decision capacity | legal or finance queue grows |
| Deployment Ready | release capacity | changes age before production |
Do not limit Done. Backlog policies are usually better expressed with prioritization and replenishment rules rather than a WIP number.
How to choose a starting limit
There is no universal formula such as “team size plus one.” Use recent flow data and treat the first number as an experiment.
- Measure the number of items in each state for two to four weeks.
- Identify the state where items wait or age disproportionately.
- Estimate the capacity that actually services that state.
- Set a limit slightly below the current typical peak—not so low that the workflow stops immediately, and not so high that nothing changes.
- Define what the team does when the limit is reached.
- Review cycle time, throughput, blocked time, and breach frequency after several weeks.
For a five-person cross-functional team, an In Progress limit of three or four may be a reasonable experiment. It is not a benchmark. A team doing pair work, support rotation, or specialist review may need a different policy.
The policy matters more than the number
When a column reaches its limit, the default response should be to help work leave that state:
- finish or review an existing item;
- remove a blocker;
- pair with the current owner;
- split an oversized item if the remaining parts are independently valuable;
- clarify a decision or acceptance criterion;
- stop pulling new work until flow resumes.
Silently moving cards backward, hiding blocked work, or raising the limit every time it is uncomfortable defeats the point. A breach is information. The team may still override a limit, but it should record why.
Should blocked work count toward WIP?
Usually yes. A blocked item still occupies attention, creates coordination cost, and delays value. Excluding it can make the board look healthy while the system accumulates unfinished work.
If the team excludes blocked items, use a separate visible blocked limit and aging policy. Never move them to an invisible holding area. The policy must answer who owns the unblock action and when escalation occurs.
Handling urgent work
An expedite lane can protect true emergencies without making every request urgent:
- set an expedite WIP limit of one;
- define eligible classes, such as an active production incident;
- require a named decision-maker;
- record which normal item was delayed;
- review every expedite item afterward.
If the expedite lane is always occupied, the problem is demand or service design, not the lane size.
Team-level limits versus personal limits
Prefer limits on workflow states. Personal limits can support focus—for example, one active primary task—but they should not become performance quotas. The system should encourage collaboration at the bottleneck rather than reward individuals for maximizing their own activity.
A developer helping Review may appear to “produce” less locally while improving total delivery. WIP limits work when the team optimizes flow, not utilization.
Reading limit breaches
A breach can indicate different causes:
- Brief and rare: normal variation or a deliberate exception.
- Frequent in one state: capacity, skill, or policy constraint.
- Several states full: arrivals exceed departures or items are too large.
- Review always full: review starts late, ownership is unclear, or changes are oversized.
- Testing full in batches: upstream work is being pushed rather than pulled.
Pair the board with a cumulative flow diagram and work-item aging. The limit shows the current constraint; trend data shows whether it is persistent.
Week 1: baseline
Record WIP, throughput, median cycle time, the 85th percentile, blocked time, and item age. Do not change the workflow yet.
Week 2: introduce one limit
Choose the most constrained active state. Write the breach policy and explain that the limit applies to the team, not individual evaluation.
Week 3: inspect exceptions
Review every breach. Was the item too large? Was a reviewer unavailable? Did urgent work enter without removing another item?
Week 4: adjust carefully
Keep, lower, or raise the limit based on flow and service quality. Change one major variable at a time so the result remains interpretable.
Metrics that belong together
- WIP by state;
- throughput per time period;
- cycle-time distribution, not only an average;
- age of open items;
- blocked time and reason;
- breach count and duration;
- quality signals such as escaped defects or rework.
Faster movement with more defects is not healthier flow. Likewise, lower WIP with collapsing throughput may mean the limit is below viable operating capacity or the constraint remains unresolved.
Common mistakes
- copying another team's numbers;
- setting limits without a pull and breach policy;
- excluding blocked work to make the board look better;
- using WIP as an individual productivity score;
- raising limits instead of addressing a persistent bottleneck;
- counting items with radically different size as equivalent;
- changing limits every few days before a trend exists;
- allowing unlimited “urgent” work.
WIP limits in WKFGo
WKFGo boards can keep workflow state, ownership, aging, workload, and flow analysis in the same project context. Use the board for the current decision, then compare the trend with cumulative flow and aging data. The tool can make the constraint visible; the team still owns the policy and response.
For the next step, read how to interpret a cumulative flow diagram.
Primary references and verification
This list supports further verification; inline links remain the source for a specific claim.