Kanban WIP limits make workload visible and protect a team from starting more work than it can finish. This guide gives you a practical method for setting, testing, and adjusting work-in-progress limits using team capacity, cycle time, blocked work, and throughput, plus reusable worksheets and scenario examples.
Overview
A work-in-progress limit is a cap on the number of active items allowed in a column or workflow stage on a kanban board. For example, a development column might allow four items, while a code review column allows two. The limit is not a productivity target and does not mean the team must always fill every available slot. It is a signal that helps people finish existing work before pulling in more.
The right limit depends on the work, the workflow, and the people available. A limit that is too high can hide bottlenecks, increase context switching, and leave tasks aging in progress. A limit that is too low can leave specialists or downstream stages idle. Treat the first number as a testable working assumption rather than a permanent rule.
Before changing limits, define what counts as “in progress.” Use consistent rules for paused, blocked, waiting-for-review, and completed items. A clear policy matters more than a precise number because inconsistent counting makes board data difficult to interpret.
For a broader view of board health, use the Kanban board audit checklist. If your team is still defining its available capacity, the method in Team Capacity Planning with a Kanban Board can provide a useful starting point.
Checklist by scenario
Step 1: Map the real workflow
List the stages work actually passes through, not just the labels on the board. A software team might use Ready, Development, Code Review, Test, and Done. A marketing team might use Briefed, Drafting, Review, Scheduled, and Published. A support team might use New, Investigating, Waiting for Customer, and Resolution.
Decide whether each stage needs its own limit. Start with stages where queues regularly form or where work frequently becomes blocked. A single limit for the entire board may be useful for a small team, but column-level limits usually reveal where flow is slowing.
Step 2: Measure team capacity
Record how many people normally contribute to each stage and how much of their time is realistically available. Account for meetings, support duties, planned leave, on-call work, and specialist dependencies. Capacity is not simply headcount. Two people may have different responsibilities, or one person may be the only reviewer for a particular type of task.
Use this worksheet during a weekly flow review:
- Stage: Name the workflow column.
- Available contributors: List the people or roles who can move work forward.
- Typical available capacity: Estimate realistic capacity for the review period.
- Current WIP: Count all items currently in the stage.
- Blocked WIP: Count items that cannot progress without an external action.
- Proposed limit: Record the limit you will test.
- Review date: Choose when you will compare the limit with actual flow.
Step 3: Use cycle time and throughput as checks
Cycle time is the elapsed time from when work starts to when it finishes, based on the boundaries you choose. Throughput is the number of items completed during a defined period. Review both measures together rather than relying on either one alone.
If a stage holds many items but throughput is not increasing, the limit may be too high or the stage may have a capacity constraint. If the limit is low and the next stage often waits for work, the limit may be too restrictive, or upstream work may not be ready. Look at the typical pattern over several review periods instead of reacting to a single unusual week.
The guide to Kanban cycle time and throughput can help your team agree on definitions and calculations.
Step 4: Set a test limit
A simple starting point is to set a limit close to the number of people who can actively advance work in that stage, then adjust for collaboration and task size. For example, a development stage with four contributors might begin with a limit of four or five. A review stage with one regular reviewer might begin with a lower limit, such as two or three, so the queue remains visible.
These are starting examples, not universal standards:
| Team | Stage | Example starting limit | Reason to test it |
|---|---|---|---|
| Software development | Development | 4–6 | Allows active work while discouraging parallel tasks for a small team. |
| Software development | Code review | 2–3 | Makes reviewer capacity and aging pull requests visible. |
| Marketing | Drafting | 3–5 | Balances writing capacity with editing and approval work. |
| Marketing | Review | 2–3 | Prevents approval queues from becoming invisible inventory. |
| Customer support | Investigating | Based on active agents | Keeps complex cases visible without treating waiting cases as active investigation. |
| Customer support | Waiting for customer | Separate policy | Separates external waiting time from work the team can actively advance. |
Support workflows often need explicit policies for urgent tickets, service targets, and escalations. See Kanban Board for Customer Support before combining all ticket states under one limit.
Step 5: Run the limit as an experiment
Choose a review window long enough to observe normal work, then record what happens. During the experiment, ask: Did items wait longer? Did blocked work decrease? Did people collaborate more? Did throughput remain stable or improve? Did urgent work repeatedly bypass the limit?
When a limit is reached, do not automatically add another item. First look for ways to finish, review, unblock, or swarm on existing work. A limit only changes behavior when the team treats it as a pull signal rather than an optional decoration on the kanban board.
What to double-check
Before changing a WIP limit, check the following:
- Item size: A column containing one very large task may hold more work than a column containing several small tasks. Consider splitting oversized items before changing the number.
- Blocked work: Decide whether blocked items count against the limit. In many workflows, counting them keeps the constraint visible; a separate blocked lane can make the reason clearer.
- Specialist bottlenecks: If only one person can test, approve, deploy, or answer a particular class of request, that constraint should influence the downstream limit.
- Expedite work: Define when urgent work is allowed and how it affects normal capacity. Otherwise, “urgent” items can quietly bypass the system.
- Board policies: Make the limit and pull rules visible on the board. A limit that exists only in a meeting is easy to forget.
- Data boundaries: Use the same start and finish points when comparing cycle time and throughput. Changing definitions can make a limit appear to work when the measurement changed instead.
Automations can support these checks by flagging a full column, aging card, or blocked item. Use automation to create visibility, not to push work into a full stage. See Workflow Automation for Kanban Boards for examples of rules that can reduce manual board maintenance.
Common mistakes
| Problem | What it looks like | Adjustment |
|---|---|---|
| Setting limits by headcount alone | The limit matches team size, but work still waits for a specialist. | Base limits on the capacity of the constrained stage, not only total team size. |
| Using limits as quotas | People pull work to fill every available slot. | Explain that the goal is flow and completion, not maximum occupancy. |
| Changing limits too often | The team cannot tell whether an adjustment had an effect. | Record each change and allow enough normal work to pass through before reviewing it. |
| Ignoring blocked cards | The board appears full, but the team reports having nothing actionable. | Mark blocked work clearly and decide how it counts in the policy. |
| Making items too large | A low WIP count hides long cycle times. | Split work into independently finishable slices where practical. |
| Applying one limit everywhere | Every column has the same number despite different capacities. | Use stage-specific limits when the work or staffing differs. |
Do not use a WIP limit to compensate for a disorganized backlog. First remove stale or unclear work and clarify priorities. The Kanban backlog cleanup checklist is useful when the board contains old, duplicate, or poorly defined cards.
When to revisit
Review limits during a regular weekly flow review, especially after the team has collected enough observations to identify a pattern. Revisit them sooner when the team structure changes, a workflow stage is added or removed, work becomes substantially larger or smaller, or a new dependency changes capacity.
Use this short review checklist:
- Compare current WIP with each column limit.
- Identify the oldest active and blocked items.
- Review cycle time, throughput, and the number of items that crossed the limit.
- Ask where work waited and whether the wait was caused by capacity, unclear policy, dependency, or item size.
- Choose one adjustment: keep the limit, lower it, raise it cautiously, split a stage, or change the workflow policy.
- Record the decision, reason, owner, and next review date.
Before seasonal planning cycles, repeat the capacity check rather than carrying old limits forward automatically. When your tools or workflow automations change, confirm that cards are still counted in the correct columns and that blocked or completed states are represented consistently. A retrospective can help the team discuss behavior and policy alongside the numbers; the Kanban retrospective template provides a structured starting point.
The practical rule is simple: set a visible limit, observe the flow, and change one variable at a time. If meeting notes or decisions regularly create unplanned cards, review how those tasks enter the board using the AI meeting notes to action items workflow. A dependable intake process makes WIP limits easier to trust and maintain.
