How to Set Work in Progress Limits on a Kanban Board

Overview

If your online kanban board looks busy but progress still feels slow, the problem is often not effort. It is usually too much work started at once. Teams open tasks early, move cards into active columns before they are ready, and carry unfinished work across meetings, days, or even sprints. The board then becomes a record of overload instead of a project tracking board that helps decisions.

That is where work in progress limits help. In kanban flow management, a WIP limit sets the maximum number of cards allowed in a stage at one time. A column with a limit of 3 can hold only three active items. If a fourth item arrives, the team must either finish something, move something back, or decide that the new item is more important than existing work.

The value is practical:

• Better focus: fewer active tasks means less context switching.
• Earlier bottleneck detection: blocked review, QA, or approval steps become visible quickly.
• Clearer prioritization: teams stop treating every request as urgent.
• More reliable flow: work moves across the board instead of aging in the middle.

WIP limits are not about slowing a team down. They are a control for protecting throughput. A good kanban board software setup uses limits to expose constraints, not to punish people. That distinction matters. If your team interprets WIP limits as a performance weapon, people will game the board. If they see limits as a flow rule, the board becomes a useful task management tool.

Before setting numbers, keep one core idea in mind: you are limiting active work, not total demand. Your backlog can be long. Your queue can be full. The WIP limit applies to the stages where people are actually working, reviewing, testing, or approving. That is why WIP limits are central to any serious kanban board template, whether you run software delivery, IT operations, support, content, or internal business workflows.

If you are still shaping your board structure, it can help to review a feature checklist for smaller teams before configuring rules in your kanban board software. See Best Kanban Board Features Checklist for Small Teams.

Step-by-step workflow

The goal of this workflow is not to find a perfect number on day one. It is to set reasonable starting limits, watch how work behaves, and adjust with evidence.

1. Map your actual workflow, not your org chart

Start with the stages work really moves through. A simple board might look like:

• Ready
• In Progress
• Review
• Testing
• Done

A more detailed board may split work into analysis, implementation, peer review, validation, release readiness, and deployment. Keep the workflow specific enough to show handoffs, but not so detailed that every card requires constant updates.

The key question is: where does work wait for attention, judgment, or specialized effort? Those are the places where WIP limits matter most.

2. Decide which columns need WIP limits first

You do not need a limit on every column immediately. Focus first on active states. In most teams, that includes:

• In Progress: to reduce overcommitment.
• Review: to reveal review queues and approval delays.
• Testing or Validation: to expose quality bottlenecks.

Backlog and Done usually do not need WIP limits. Ready may or may not need one depending on how your team handles intake. If a large Ready column causes confusion, a soft limit there can help force stronger prioritization.

3. Count available attention, not headcount alone

Many teams set limits by matching the number of people in a stage. That can work as a starting point, but it is often too simple. A better approach is to estimate available attention.

For example, if you have five engineers but only three are spending most of the week on active delivery, an In Progress limit of 5 may still be too high. Likewise, if one senior reviewer handles most approvals, the Review limit should reflect that real constraint.

Use questions like these:

• How many people actively pull work in this stage?
• How much of their week is available for that stage?
• Do tasks here require deep focus or quick touches?
• Is there one specialist who creates a natural bottleneck?

As a starting point, many teams do well with a limit that is slightly lower than the number of people who could work in the stage full time. That encourages collaboration and finishing behavior rather than constant starting.

4. Start with conservative numbers

If you are unsure how to set WIP limits, lower is usually better than higher. A high limit rarely changes behavior. A modest limit creates a useful pause.

Example starting points for a seven-person delivery team might be:

• In Progress: 4
• Review: 2
• Testing: 2

These are not universal numbers. The point is to begin with limits that require choices. If your current board has 11 cards in progress and none seem close to done, dropping the limit to 10 will not change much. Dropping it to 4 or 5 probably will.

5. Define what counts as "in progress"

This is one of the most important parts of WIP limits kanban teams often skip. If card states are vague, limits become easy to bypass.

Set explicit entry and exit rules for each active column:

• In Progress: work has been accepted, dependencies are known, and someone has started execution.
• Review: the output is complete enough for review; the reviewer does not need to wait for missing parts.
• Testing: the item is stable enough to validate.

Without these rules, a team may move work forward just to free space, which hides the bottleneck instead of solving it.

6. Choose how to handle blocked work

Blocked items distort limits if you do not decide where they belong. There are two common patterns:

• Blocked items stay in the active column: this keeps pressure on the system and makes blockers visible.
• Blocked items move to a separate blocked lane: this improves clarity, but you should still count them against the relevant stage unless you have a strong reason not to.

In most cases, blocked work should still count. Otherwise teams can escape limits by relabeling stalled items.

7. Make the policy visible on the board

A WIP limit that lives only in team memory will not last. Use your task board app or work management software to display the limit on each column. Add a short policy note such as:

• Pull only when below the limit.
• If the limit is exceeded, swarm before starting new work.
• Escalate blocked items after one business day.

This turns the board from a passive status display into an operating system for daily decisions.

8. Agree on the response when a limit is hit

The limit itself is only half the practice. The real value comes from what happens next. When a column reaches its cap, the team needs a standard response. Common options include:

• Help clear review or testing instead of starting a new task.
• Split a large item into smaller pieces if practical.
• Escalate a dependency or approval delay.
• Reprioritize and explicitly pause a lower-value item.

This is why WIP limits work well for technology teams dealing with disconnected tools and manual updates. They create a shared protocol for saying, "stop starting, start finishing."

9. Review the limits after two to four weeks of real use

Do not judge the system after one busy day. Let the board run long enough to show patterns. Then review:

• Which columns fill first?
• Where do cards age the longest?
• Which limits trigger healthy collaboration?
• Which limits create noise without helping flow?

If one stage is constantly full while upstream stages stay active, you have found either a true capacity constraint or a board design problem. Both are useful findings.

10. Adjust one variable at a time

When tuning limits, avoid changing everything at once. If you raise In Progress, lower Review, rename columns, and change card size in the same week, you will not know what caused the effect.

Make one adjustment, observe it, and document why. That gives your team a reusable method for future recalibration when staffing or demand changes.

Tools and handoffs

The right kanban board software can make WIP limits easier to use, but tools do not replace policy. Your board should support the workflow, not define it for you.

What to configure in your kanban board software

Look for features such as:

• Column-level WIP limits
• Visual warning when a limit is exceeded
• Card aging or cycle time indicators
• Blocked item markers
• Custom fields for owner, service area, or dependency type
• Automation rules for alerts or handoff reminders

An online kanban board becomes much more useful when these features are paired with explicit operating rules. For a broader view of what to evaluate in a task management tool, see Best Kanban Board Features Checklist for Small Teams.

How handoffs affect WIP limits

Most kanban bottlenecks show up at handoff points, not within a single person's work. Examples include:

• Developer to reviewer
• Engineer to security approver
• Analyst to stakeholder signoff
• Operations owner to change window approval

If these handoffs happen in email, chat, or meetings instead of on the board, your limits will look cleaner than reality. To avoid that, define one visible handoff trigger inside the board. For example:

• Moving a card to Review automatically pings the reviewer.
• Moving a card to Testing adds a checklist and assigns QA.
• Blocked cards require a reason code and next follow-up date.

This is where lightweight workflow automation software can help. Simple automations reduce manual status chasing and preserve the integrity of the flow. They also help teams who are tired of repetitive admin work.

Use class of service carefully

Some teams need an expedite lane for urgent incidents or compliance work. That is reasonable, but keep it narrow. If everything can bypass limits, the board stops being trustworthy.

Set clear rules for exceptions:

• Who can declare an expedite item
• How many expedite items can exist at once
• How the team recovers normal flow after the interruption

For teams deciding between a continuous flow model and timeboxed planning, it can help to compare operating assumptions. See Kanban vs Scrum Boards: Which Workflow Fits Your Team in 2026?.

Keep card size realistic

WIP limits are harder to interpret when one card represents two hours of work and another represents three weeks. You do not need perfect sizing, but you do need roughly comparable units. If large tasks dominate the board, split them before they enter active work. Otherwise one card may occupy a slot so long that the limit creates frustration instead of clarity.

Quality checks

Once limits are in place, the team needs a few simple checks to confirm that the system is improving flow rather than just changing appearances.

Check 1: Are limits changing behavior?

If every column still runs hot and people keep starting new tasks without discussion, the limit may be too high or not enforced. A useful WIP limit should occasionally force a decision.

Check 2: Are bottlenecks becoming visible?

A healthy board makes queues obvious. If review is always full, that does not mean WIP limits failed. It means the board is showing you where capacity or policy is misaligned. That visibility is the point.

Check 3: Is work aging less in the middle?

You do not need advanced analytics to spot improvement. Look at how long cards sit in active stages compared with a few weeks earlier. If items move through more steadily, your limits are probably helping.

Check 4: Are people collaborating more across stages?

One of the best signs of effective limits is swarming behavior. When implementation is full but review is the blocker, people help unblock review. In a mature personal kanban board or team board, this shift from individual utilization to system flow is a major improvement.

Check 5: Are exceptions staying rare?

If expedite work, hidden side tasks, or off-board updates are becoming common, your official process may no longer match reality. Review demand patterns, service commitments, or board design before simply raising every limit.

Common mistakes to avoid

• Setting limits by instinct and never revisiting them: starting numbers are temporary.
• Using WIP limits as a utilization target: a full column is not automatically healthy.
• Ignoring blocked work: blocked cards are part of your system load.
• Making limits punitive: blame reduces transparency.
• Keeping oversized tasks on the board: large cards consume slots without producing flow.
• Adding too many columns too early: complexity weakens decision-making.

If your team uses AI assistants for meeting notes or work summaries, keep them in a support role. They can help summarize blockers or handoff notes, but they should not quietly rewrite the board's state without human review. Board integrity matters more than automatic motion.

When to revisit

WIP limits are not a one-time setup. They should be revisited whenever the underlying inputs change. A good rule is to review them on a fixed cadence, such as monthly or quarterly, and also after major workflow shifts.

Revisit your limits when:

• The team size changes
• A specialist joins or leaves
• You add a new approval, QA, or security step
• Demand increases sharply
• Task size changes due to a different kind of project
• Your kanban board software adds new automation or reporting features
• The board consistently exceeds one limit for several weeks
• Cycle time feels unstable even when utilization appears high

Use a short recalibration routine:

1. Review the current board and note where work accumulates.
2. List any staffing or workflow changes since the last review.
3. Check whether blocked work is being counted honestly.
4. Adjust one limit or one policy rule only.
5. Run the new setting for a few weeks.
6. Document what changed and what happened.

This simple routine is what makes the article's advice evergreen. You do not need a perfect formula. You need a repeatable process your team can return to when conditions change.

If you want one practical starting point, use this:

• Set limits only on active columns.
• Start lower than feels comfortable.
• Count blocked work.
• Define what qualifies for each stage.
• Agree on what the team does when a limit is hit.
• Revisit the numbers after real usage, not guesswork.

That approach works for a small business project management board, an agile kanban board for software delivery, or a personal kanban board for individual focus. The board may differ, but the logic stays the same: make work visible, limit what is active, and use the resulting friction to improve the system.

In practice, the best WIP limits are not the most sophisticated ones. They are the ones your team understands, follows, and updates as work evolves. If your board helps you decide what to start, what to stop, and what to finish next, your limits are doing their job.