Kanban WIP Limits: How to Set, Calculate, and Improve Work in Progress

Overview

Work in progress, or WIP, is everything that has been started but not finished. On a kanban board, that may include tickets in development, requests waiting for review, incidents being investigated, or changes queued for deployment. A WIP limit is a deliberate cap on the number of items allowed in a workflow stage or group of stages.

The purpose is not to keep people busy by filling every available slot. The purpose is to expose capacity constraints and encourage the team to complete existing work. When too many items are active, context switching increases, blocked work becomes harder to see, and tasks spend more time waiting between handoffs. A clear limit turns those problems into visible signals on the kanban board workflow.

A WIP limit is not a permanent productivity target. It is a working hypothesis about how much concurrent work the team can handle without creating avoidable delay. The right limit depends on team size, work type, service expectations, dependencies, review capacity, and the amount of interruption in the workflow.

Two useful ways to set a starting limit

1. Capacity-based: Start with the people or roles actively working in a stage. A simple initial rule is one item per active contributor, with a small adjustment for collaboration. For example, a development column with four contributors might begin with a limit of four or five items.
2. Data-based: Review recent work and identify how many items were commonly active while the team still completed work at a sustainable pace. Use this as a starting range rather than treating it as a precise answer.

These approaches can be combined. If the capacity-based limit feels too restrictive or too loose, compare it with recent cycle time, throughput, blocked items, and queue growth. Teams using a task management tool or online kanban board can usually record these observations directly on the board or in a lightweight review log.

For related workflow design, see Kanban Board Templates for IT Teams. The same principles can be adapted for incident response, service requests, software delivery, and operational projects.

Checklist by scenario

For a new development workflow

• Map the actual steps from ready work to completed work. Include review, testing, deployment, and other queues that regularly delay delivery.
• Separate stages that require different skills or have different capacity constraints. A single broad “In Progress” column can hide a testing or review bottleneck.
• Count the people who can actively move work in each stage, not only the total team size.
• Set an initial limit close to the number of active contributors in the constrained stage.
• Define what counts toward the limit. Decide whether blocked items, subtasks, or paired work count as one item or more than one.
• Agree on the response when a limit is reached: swarm on existing work, resolve a blocker, review a pull request, or improve the workflow.

For IT operations and help desk work

• Separate urgent incidents from standard requests if they follow different service paths.
• Use a visible blocked or waiting state so work that depends on a customer, vendor, or another team does not quietly consume active capacity.
• Set limits for investigation, remediation, and verification rather than allowing every ticket to remain active at once.
• Account for interruptions. If engineers are frequently pulled into incidents, start with a lower planned-project limit or reserve explicit capacity for unplanned work.
• Review aging items alongside the WIP count. A column at its limit may still be healthy if items move steadily; a lower count may conceal stalled work.

An IT help desk kanban board can make these distinctions easier to maintain because ticket type, priority, escalation status, and ownership can remain visible without mixing every queue together.

For a small team or personal kanban board

• Begin with a total active-work limit rather than creating many narrow limits.
• Choose a limit that makes unfinished work uncomfortable but still allows normal collaboration and interruptions.
• Keep a separate “Next” or “Ready” queue so the active limit applies only to work that has genuinely started.
• Use a blocked marker and a short reason. Without this, a small board can look active while the real constraint remains hidden.
• Review whether the limit is protecting focus or merely preventing useful work from entering the board.

Reusable WIP-limit worksheet

Copy this worksheet into your project notes or use it during a team review:

• Workflow stage: ____________________
• What counts as active: ____________________
• People or roles able to move work: ____________________
• Current limit: ____________________
• Recent typical WIP: ____________________
• Items currently blocked: ____________________
• Observed bottleneck or waiting reason: ____________________
• Recent throughput: ____________________ items completed per week or review period
• Recent cycle-time pattern: ____________________
• Proposed limit and reason: ____________________
• Review date: ____________________

What to double-check

Before changing a limit, check whether the board reflects the real workflow. A WIP count is only useful when the team applies consistent definitions.

Check the unit of work

One large project card and one small maintenance ticket should not automatically be treated as equivalent. You may still count each as one item for simplicity, but record size, class of service, or work type when those differences affect flow. If large items dominate cycle time, splitting work may be more effective than simply raising the limit.

Check queues and blocked work

Work waiting for review or deployment is still part of the delivery system, even if nobody is actively editing it. Decide whether those items belong under a stage limit or under a separate queue limit. Avoid moving cards to an artificial “done” state just to make the numbers look better.

Check cycle time and throughput together

Cycle time is the elapsed time from an agreed start point to completion. Throughput is the number of items completed in a defined period. If WIP rises while throughput stays flat and cycle time grows, the system may be overloaded. If a lower WIP limit causes items to wait because a stage is underused, the limit may be too restrictive or the workflow may need a different design.

Do not use one unusual week as the basis for a permanent change. Compare several comparable review periods where possible, and note major events such as releases, outages, holidays, or staffing changes.

Check the policy at the board level

Write a short policy next to each limit. State what counts, what happens when the limit is reached, and who can change it. In kanban board software, a visible policy can be more useful than a hidden configuration because it gives the team a shared reference during planning and daily coordination.

Common mistakes

• Setting limits as performance quotas: A limit is a constraint on concurrent work, not a target for how many tasks each person should carry.
• Using the total headcount: A team of eight may have only two people able to review, test, or deploy. The constrained stage usually deserves the closest attention.
• Making every column use the same number: Different stages often have different capacities. Identical limits can hide rather than solve an imbalance.
• Ignoring blocked cards: Blocked work consumes attention and may occupy a scarce slot. Mark it clearly and discuss how it will be unblocked.
• Raising the limit to clear an uncomfortable queue: A higher limit can make congestion less visible without increasing completion capacity.
• Changing limits too frequently: Teams need enough time to observe the effect of a change. Adjust one meaningful variable at a time when practical.
• Optimizing local utilization: Keeping every specialist busy can slow the overall flow if work piles up at review, testing, or deployment.
• Confusing prioritization with WIP control: A prioritization system decides what should be done next; a WIP limit controls how much can be active. Use both together. The task prioritization matrix can help decide what enters the workflow.

When to revisit

Review WIP limits on a regular but not excessive schedule. A short review every few weeks or at the end of a planning cycle is often enough for a stable workflow. Revisit sooner when the underlying conditions change.

Use this review checklist

• Has the team, role mix, or available working time changed?
• Has the workflow gained or lost a stage, approval, integration, or automation step?
• Are items waiting longer in one stage than in others?
• Has cycle time increased without a corresponding change in item size or priority?
• Has throughput changed after the last limit adjustment?
• Are blocked items accumulating for the same reason?
• Are urgent requests regularly bypassing the normal policy?
• Does the limit encourage collaboration, or does it create avoidable idle time?
• Do upcoming seasonal planning cycles require a different service mix or capacity assumption?
• Does the board still match the workflow used by the team?

When a tool, integration, or workflow changes, record the change beside the next WIP review. Automation can reduce manual handoffs, but it can also move queues faster into a stage that lacks capacity. Treat the board configuration and its limits as part of the operating system of the team, not as a one-time setup.

Finish each review with one small decision: keep the limit, lower it, raise it, split a stage, change the definition of active work, or investigate a blocker. Then set a date to inspect the result. This creates a repeatable improvement loop without turning the kanban board into another reporting exercise.

For a broader planning routine, pair this review with a team capacity planner and a weekly prioritization review. Together, these practices help a kanban board remain a practical project tracking board rather than a list of everything the team hopes to do.