WIP Limits
A Kanban practice that restricts the number of work items allowed in each workflow stage, forcing teams to finish work before starting new work.
What it is
Work In Progress (WIP) limits are a foundational Kanban practice that cap the number of work items allowed in each stage of a workflow. When a column reaches its limit, no new items can enter until something moves forward.
This creates a pull system: work is pulled into the next stage only when there is capacity, rather than pushed forward regardless of downstream ability to handle it.
- Each column has a max. The limit is displayed on the Kanban board, usually in the column header.
- When full, no new items enter. Team members must help clear work from the bottleneck column before starting something new.
- Forces teams to address blockages. Instead of starting fresh work, the team swarms to resolve stuck items.
- Reduces context switching. Fewer concurrent tasks means deeper focus and higher quality.
WIP limits apply to columns, not people. A limit of 3 in "In Progress" means 3 items total in that stage, regardless of how many developers are on the team.
When to use it
Implement WIP limits as soon as you begin using a Kanban board. They are not an advanced technique—they are the mechanism that makes Kanban work.
Start with a limit that feels slightly uncomfortable. If it never feels tight, it is probably too high.
Key concepts
The Pull System
Work moves right when the next stage has capacity to pull it. This prevents overloading downstream stages and keeps flow smooth.
Setting Limits
A common starting point is the number of team members plus one. For a team of 6, try a limit of 7 in "In Progress" and 3 in "Code Review." Adjust based on observed behaviour.
If your limit is never reached, lower it. If it is constantly breached with valid reasons, you may need to raise it—or fix the reasons for the breaches.
WIP Limit Breaches
A breach occurs when work enters a column that is already at its limit. Breaches are signals, not failures. They indicate a policy decision, a blocked item, or a limit that needs adjustment.
Team vs Individual WIP
Limit work at the team level. Individual WIP limits create silos and discourage collaboration. The goal is to finish work, not to optimise individual utilisation.
WIP Limit Calculation Methodology
Formula: WIP Limit = (Team Size × Average Items per Person) + Buffer
Explanation:
- Team Size: 6 developers = 6
- Average Items per Person: On average, how many work items does one person work on before finishing? Usually 1 (one task at a time is ideal, but some people multitask or have waiting time). Use 1 if possible.
- Buffer: Add 1-2 to allow for slight overflow when someone needs to unblock a peer.
Examples:
- Team of 6, ideal state (1 item per person): 6 × 1 + 1 = 7 WIP limit
- Team of 10, realistic (some waiting, some multitasking): 10 × 1.2 + 2 = 14 WIP limit
- Team of 4 with high context switching: 4 × 1.5 + 1 = 7 WIP limit (same as team of 6, because of inefficiency)
Worked Example: Calculating Optimal WIP for a 6-Person Team
Team composition: 4 backend developers, 1 frontend developer, 1 QA engineer
Workflow stages: "To Do" → "In Progress" → "Code Review" → "In Test" → "Done"
Baseline observation (no limits):
- "In Progress" average: 12 items (people start too much)
- "Code Review" average: 8 items (review is slow, items pile up)
- "In Test" average: 5 items (QA is one person, can't keep up)
- Lead time: 20 days (too long)
Proposed limits (conservative to start):
- "In Progress": 6 (one per person, forces finishing before starting new)
- "Code Review": 4 (slow it down, catch quality earlier)
- "In Test": 3 (protect the QA, don't dump untestable work)
Result after 2 sprints:
- Items complete faster (cycle time drops from 8 days to 4 days)
- Focus improves (less context switching)
- Lead time drops to 12 days
- Quality goes up (code is more thoroughly reviewed because bottleneck is visible)
- But: "In Progress" limit is breached twice (urgent bugs pushed in, agreed on policy exception)
Refinement: After 2 months, team decides WIP limits are working. They lower "Code Review" to 3 (easier to review now, less backlog), keep "In Test" at 3 (QA still the constraint).
Experiment Framework: Try WIP Limit, Measure Impact
- Baseline (Week 1-2): Measure current state. Record: cycle time, lead time, blocker frequency, team morale.
- Set limits (Week 3): Propose WIP limits based on team size. "To Do" doesn't have a limit. "In Progress" = 1 per person. "Code Review" = 50% of In Progress. "In Test" = 2-3 (depends on team).
- Run experiment (Week 3-6, one sprint): Use the limits strictly. Treat breaches as learning, not failure.
- Measure (Week 7): Compare to baseline. Did cycle time improve? Did lead time improve? Did team morale change? Did blocker rate change?
- Adjust (Week 8): Based on data, tweak limits. If "Code Review" is always full but "In Test" is empty, lower code review limit and raise test limit.
- Iterate: Run another cycle. Measure again in 4 weeks.
What Happens When WIP is Too High
- Context switching: A developer with 4 items in progress switches between them constantly. Each switch has a 10-minute ramp-up cost. Productivity drops 40%.
- Slow delivery: With 20 items in "In Progress," nothing finishes. Lead time balloons to 30+ days.
- Quality issues: Rushed code, incomplete tests, sloppy review. Bugs hidden until late stages, expensive to fix.
- Blocker visibility: With high WIP, blockers hide. A team member can look busy (many items started) while actually stuck (all items blocked).
- Team burnout: Switching constantly feels chaotic. Team feels busy but unproductive. Morale drops.
Tools for Enforcing WIP Limits
- Physical Kanban board: Index cards in columns. Limits are visible as physical space. When a column is full, you stop filling it.
- Jira: Set "Issue Limit" on each board column. Jira flags when limit is exceeded.
- GitHub Projects: Columns support limits (beta feature in some versions). Use a rule to warn when limit is approached.
- Azure DevOps: Built-in WIP limits on board columns. Easy to set and enforce.
- Trello Power-Ups: Third-party integrations that show WIP limit badges on columns.
Common pitfalls
| Pitfall | Why it hurts | What to do instead |
|---|---|---|
| Limits too high | No tension in the system; work piles up silently. | Lower until the limit is occasionally uncomfortable. |
| Ignoring limits for "urgent" work | Every item becomes urgent; limits become meaningless. | Escalate the limit temporarily and record the reason. |
| Same limit for every column | Stages have different capacities and purposes. | Tailor limits to each stage based on flow data. |
| Treating breaches as failure | Team hides breaches rather than learning from them. | Treat breaches as data. Discuss in standups. |
| Not adjusting limits | Team composition and work types change over time. | Review limits in retrospectives at least monthly. |
NZ context
New Zealand software teams are often small—5 to 7 people. At this scale, modest WIP limits have dramatic effects. A limit of 5 in "In Progress" for a 6-person team forces collaboration and exposes blockages within days rather than weeks.
Many NZ teams operate in mixed waterfall-agile environments where upstream business analysts or product owners push work regardless of capacity. WIP limits give the delivery team a concrete policy to push back: "The board is full. We can pull this when something moves."
Career level guidance
Junior: Respect the WIP limit. When your column is full, ask how you can help move existing work forward rather than starting something new. Learn to see the limit as a team tool, not a personal restriction.
Senior: Help set initial limits and coach others through breaches. Watch for patterns—if one column is always full, that is where your process improvement effort belongs.
Test Lead: Use WIP limits to protect test capacity. A dedicated "In Test" column with a strict limit prevents the team from dumping untestable work and walking away. Review limit data in retrospectives and adjust based on release cadence.
Industry Reality
- Most teams set WIP limits once during a Kanban training workshop, then quietly raise them whenever they feel inconvenient — effective limits end up 2–3x the original value within three months, erasing the benefit.
- In practice, "urgent" items are the most common reason for breaches; without a written policy about what constitutes a genuine emergency, every ticket eventually becomes urgent and the limit becomes decorative.
- Senior practitioners treat WIP limit breaches as a lagging indicator of upstream dysfunction — too many breaches in Code Review usually means story sizing is off or acceptance criteria are unclear at story-kick-off, not that the limit is wrong.
- Many NZ agile teams use Jira column limits but never configure the enforcement feature; the number sits in the column header while the board silently holds 15 items labelled "In Progress" for the whole sprint.
- The "one piece of work at a time" ideal rarely survives contact with support rosters, back-to-back meetings, or cross-team dependencies — experienced practitioners negotiate a personal WIP of two, then protect it fiercely rather than pretending they can do one.
Context guide
How the right level of WIP Limits effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| Revenue NZ or Revenue NZ tax-portal teams with a single QA engineer | Essential | One QA testing eight tax-calculation stories simultaneously produces shallow coverage. A strict "In Test" WIP of 2–3 is the difference between a production defect and a caught one on a high-trust government service. |
| Small NZ startup (4–6 people) doing continuous deployment | Essential | At small scale each person is a significant fraction of total capacity. Without limits, one person blocked by a code review stops everything; the limit forces the team to swarm and unblock rather than start fresh work. |
| CoverNZ or Benefits NZ delivering regulated social-service software on two-week Scrum sprints | High | Sprint boards with 20+ concurrent "In Progress" items hide blockers and produce half-tested stories at demo. A per-column cap surfaces bottlenecks mid-sprint when they are still fixable, not on the last day. |
| Harbour Bank or Pacific Bank digital banking squad with cross-team API dependencies | High | External dependencies cause stories to park in "Waiting" for days. Without a WIP limit, the team keeps starting work and the board fills with blocked items that appear active. Limits force the team to flag and escalate blocks early. |
| Large waterfall-adjacent programme (e.g., HealthNZ / HealthNZ national system rollout) | Medium | Governance gates and sign-off queues dominate cycle time more than team WIP. Limits still help at the team level but require senior buy-in before they can override delivery-manager pressure to "just start everything now." |
| Solo contractor or freelance QA on a fixed-scope engagement | Low | WIP limits are a team coordination tool. A solo contractor can still use a personal limit (max two active items) but formal Kanban column caps require a board and a team to enforce them. |
Trade-offs
What you gain and what you give up when you adopt WIP Limits.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Bottlenecks surface in days, not weeks — a full column is an immediate signal that demands a conversation. | Initial discomfort causes teams to raise limits quietly rather than fix root causes, negating the benefit within a few sprints. | Your bottleneck is external governance (sign-off queues, vendor dependencies) that the team cannot resolve by swarming — address the governance process first. |
| Cycle time drops measurably (Little's Law) — less concurrent work means each item reaches "Done" faster, which improves release predictability for stakeholders. | Requires discipline to enforce during high-pressure periods — deadline pressure from product owners or business analysts commonly triggers ad-hoc breaches that erode the policy. | Your team has a genuine emergency (production outage, Privacy Act 2020 breach response) that justifies temporary WIP expansion — log it, set an end date, and revert explicitly. |
| Upstream developer behaviour improves — a tight "In Test" limit creates backpressure that encourages smaller stories and clearer acceptance criteria before handover to QA. | Can feel punitive to individuals who are genuinely done with their task and want to be productive — requires cultural shift from "start things" to "finish things." | Your team size is one or two people — personal task management (a simple to-do list with a self-imposed cap) is more pragmatic than a formal column limit. |
| Provides a concrete, data-driven basis for pushing back on unrealistic loading from upstream stakeholders — "the board is at limit" is harder to argue with than "we're busy." | Choosing the wrong initial limit (too high) means the team never feels flow pressure, and the limits become decorative numbers that no one revisits. | You have no board at all — introduce a visual workflow first (physical board or Jira columns) before adding limits, otherwise the policy has nowhere to live. |
Enterprise reality
How WIP limits change when you are coordinating 200–300 developers across 10+ squads in a NZ enterprise context
- WIP limit enforcement moves from team discipline to automated policy: tools like Jira Advanced Roadmaps or Azure DevOps enforce column caps at the programme level and flag breaches in dashboards that delivery managers review daily — no one waits for standup to notice a blocked column.
- Governance and compliance obligations harden the "In Test" limit into a contractual constraint: under the Privacy Act 2020 and NZISM, regulated organisations such as Revenue NZ and HealthNZ must demonstrate evidence of controlled, documented testing before release — a WIP limit breach in "In Test" that allows untested code to proceed creates an audit liability, not just a quality risk.
- Harbour Bank's technology division operates with dedicated flow engineers who own WIP limit policy across the bank's delivery squads — setting column caps is not left to individual teams but is governed by a delivery engineering function that analyses cumulative flow data across all squads weekly and adjusts limits programme-wide when bottlenecks migrate between stages.
- Cross-squad WIP becomes the dominant concern: when 10+ squads share a single release pipeline, the real constraint is rarely one team's "In Progress" column — it is the shared environments, shared API teams, or shared QA infrastructure whose capacity determines the effective WIP limit for the whole programme; enterprise teams instrument these shared stages and set programme-level WIP limits rather than only per-squad limits.
◆ What I would do
Professional judgment — when to adopt WIP Limits, when to adapt it, and what to watch for.
The bottom line: Always set the "In Test" limit first and set it lower than feels comfortable — a QA engineer who cannot go deep on any single story is not testing, they are triaging, and the defects that matter most will slip through.
Best Practices
- ✓ Start with team size + 1 as your initial limit for "In Progress", then lower it by one each fortnight until the team feels productive tension — this data-driven descent is faster than guessing the right number upfront.
- ✓ Set a separate, lower limit for review stages (Code Review, In Test) than for active work stages; review is typically the bottleneck and deserves a tighter cap.
- ✓ Write a WIP limit policy document (even one paragraph) that defines what a legitimate breach looks like — production outages, yes; "I just want to start something while I wait" is not a breach reason.
- ✓ Track breach frequency and reasons in your retro board; if the same reason appears three sprints running, adjust the limit or fix the root cause rather than accepting the exception.
- ✓ Protect the "In Test" column limit aggressively — a QA engineer with 8 items to test has zero ability to test any of them properly; a limit of 2–3 forces developers to write better acceptance tests before handover.
- ✓ Review and adjust limits at every monthly retro, not just when they feel painful — team size, velocity, and work types all change, and a limit set in March may be wrong by June.
- ✓ Use cumulative flow diagrams alongside WIP limits; a widening band in any stage is a signal to tighten that column's limit before it becomes a crisis.
- ✓ When a WIP limit is hit, hold a brief swarming conversation at standup — who can pair or unblock the stuck item — rather than routing the conversation to Slack where it gets lost.
Common Misconceptions
❌ Myth: WIP limits slow the team down by stopping people from starting work.
Reality: WIP limits increase throughput by reducing the queue depth in each stage. Little's Law shows that average lead time equals average WIP divided by throughput rate — lowering WIP directly lowers lead time, so the team delivers completed features faster even though individuals appear to start fewer things.
❌ Myth: WIP limits are a Kanban-only rule that doesn't apply to Scrum teams.
Reality: Nothing in the Scrum Guide prevents WIP limits, and many high-performing Scrum teams apply them to board columns within a sprint. A sprint backlog with 40 stories "In Progress" simultaneously is just chaotic Scrum; a WIP limit of 6 in "In Progress" restores the focus a two-week sprint is supposed to provide.
❌ Myth: The right WIP limit is a fixed formula — just calculate team size and you're done.
Reality: Formulas give you a starting estimate, not an answer. The optimal limit depends on your mix of work types, number of external dependencies, meeting load, and team experience. Teams that treat the first limit as final miss the continuous improvement that Kanban is designed to surface — the limit should evolve every month or two based on actual flow data.
Prerequisites
Related Techniques
What to Learn Next
Senior engineer insight
Teams that use WIP limits well treat the limit as a team conversation starter, not a traffic light — when the column fills, the instinct to swarm on the bottleneck rather than find workaround work is what separates high-flow teams from chronically-busy ones. The single pattern that reliably works is setting the "In Test" limit lower than the "In Progress" limit from day one: it creates healthy upstream pressure that forces developers to write cleaner acceptance criteria and smaller stories before handover, rather than discovering problems at the last stage.
The most common mistake is treating WIP limits as a permanent configuration rather than an evolving dial — teams set them once in a workshop, never revisit them, and within two months the limits have been quietly raised to match actual behaviour instead of driving improvement.
From the field
A Wellington-based payments team using Kanban assumed their "In Test" WIP limit of 8 was reasonable for a squad of 9 — after all, no one was idle. In practice their sole QA engineer was triaging eight stories simultaneously, spending so much time switching context that no single story ever got deep exploratory coverage. After a production defect slipped through on a high-value transaction flow, the team cut the "In Test" limit to 3 and added a policy: developers could not push to "In Test" without attaching a test-coverage summary. Within a fortnight, stories started arriving with edge cases already documented, developers began pairing on test prep before handover, and defect escape rate dropped to near zero over the following quarter. The lesson that travels beyond that team: a low "In Test" limit changes developer behaviour upstream far more effectively than any QA training programme.
Why teams fail here
- Setting every column limit at team size — this removes tension from review and test stages where bottlenecks actually form, and means the limit is never meaningfully reached in practice.
- Allowing open-ended "urgent" exceptions without logging them — within weeks, urgency becomes the default justification and the board reverts to its pre-limit state while the column numbers remain as decoration.
- Applying WIP limits to columns but not addressing the upstream push habit — product owners or business analysts continue loading the "To Do" column with fifty items, creating invisible WIP that the limit never captures.
- Abandoning limits after the first uncomfortable sprint instead of investigating what the discomfort is signalling — the moment flow pressure reveals a real bottleneck is precisely when the limit is doing its job, but teams often interpret it as a sign the limit is wrong rather than the process.
Key takeaway
A WIP limit is not a rule about how much work a team can handle — it is a forcing function that makes invisible bottlenecks impossible to ignore, turning accumulated queue depth into a visible team conversation about where the real constraint lives.
How this has changed
The field moved. Here is how WIP Limits evolved from its origins to current practice.
WIP limits originate in Toyota's kanban system. Each stage holds a fixed number of cards — when full, no new work enters until a card leaves. This prevents overproduction and forces attention to flow.
David Anderson introduces WIP limits to software via Kanban. Counter-intuitive insight: limiting work in progress speeds delivery by reducing multitasking and context switching. "Stop starting, start finishing."
Teams discover that WIP limits expose process problems — when a limit is hit and work stops, the team must resolve the blocker. This creates pressure to fix systemic problems rather than work around them.
WIP limits spread to Scrum teams and to the organisation level — limiting simultaneous initiatives prevents strategic overload.
AI-assisted flow management tools automatically recommend WIP limit adjustments based on throughput and queue data. The principle extends to AI system queues and API rate limiting — the same logic applies to any system with capacity constraints.
Check Your Understanding
Click each question to reveal the answer.
Q: Your team is testing a new Revenue NZ myIR portal feature. Three stories are already in "In Test" with a WIP limit of 3, and developers push a fourth story that includes a complex tax calculation. What should you do, and why?
A: Enforce the limit and decline to pull the fourth story until one of the three in flight is complete or returned. A QA engineer spread across four complex items — especially one involving Revenue NZ tax calculation logic — cannot test any of them thoroughly, which risks a defect reaching production on a high-trust government service. If the fourth story is genuinely urgent, raise the breach transparently at standup, log the reason, and negotiate which current item gets deprioritised or returned to "In Progress" to make room.
Q: An CoverNZ claims-processing team runs Scrum with two-week sprints. During sprint planning they commit to 22 stories "In Progress" at once. A team member says WIP limits only apply to Kanban boards, so they don't need them. How do you respond?
A: WIP limits are not Kanban-exclusive — they address a flow problem that affects any board-based workflow, including Scrum. The Scrum Guide does not prohibit WIP limits, and nothing about a two-week cadence prevents applying a column cap. With 22 stories simultaneously "In Progress," cycle time will balloon, context switching will reduce quality, and blockers will hide behind apparent busyness. Applying a WIP limit of roughly team size + 1 within the sprint board will surface bottlenecks earlier and produce more stories fully done by sprint end — which is precisely what Scrum's Definition of Done requires.
Q: What is the key difference between a WIP limit and a sprint commitment in Scrum, and when would you prefer each?
A: A sprint commitment is a time-boxed forecast of total work the team plans to complete in the sprint — it controls scope at the start. A WIP limit is a continuous flow constraint that controls how many items are active in any single stage at any moment — it controls quality and focus throughout delivery. Sprint commitments help with predictability and stakeholder communication; WIP limits help with cycle time and blocker visibility. High-performing teams often use both: the sprint commitment defines what enters the sprint, and WIP limits govern how it flows through. If your team suffers from slow cycle times or hidden blockers mid-sprint, add WIP limits even if you already have sprint commitments.
Q: A developer on a KiwiSaver provider project says: "WIP limits slow us down — if I finish my task early I should be able to start the next one instead of sitting idle." What is wrong with this reasoning and how do you respond?
A: The developer is optimising for individual utilisation rather than team throughput — a common and costly mistake. Little's Law shows that lower WIP directly reduces average lead time, so the team delivers completed features faster overall even though individuals appear to start fewer things. "Sitting idle" is rarely the reality: when a column is full, the right action is to swarm on the bottleneck — pair review a colleague's code, help unblock a stuck story, or write better test coverage for items awaiting QA. Starting new work when downstream stages are full just adds to queue depth, hides blockers, and increases the chance that half-finished KiwiSaver features pile up at the end of the sprint when they are most expensive to test and fix.