Set Work-in-Progress Limits Around the Real Bottleneck

Overview

Set work-in-progress limits around the amount of unfinished work the process can handle, then use those limits to decide what the team should finish or unblock before starting more. The number on the board is a decision aid. It cannot create missing skills, remove an approval dependency, or make an overloaded service sustainable by itself.

Work in progress, often shortened to WIP, is work that has started but has not reached the defined finish point. A proposal waiting for approval is still unfinished. So is a repaired device awaiting its final check. If the board hides those waiting states, its limit will describe only part of the team's actual commitments.

Kanban guidance emphasizes defining and visualizing the workflow, actively managing items, and improving how work moves. This guide applies those principles to ordinary business operations through a worked example and practical decision rules.

Choose a meaningful start and finish

Define when the team commits to doing an item and when the customer or next process can use the result. Those boundaries determine what belongs in WIP.

For a proposal team, “started” might mean that a qualified opportunity has been accepted for proposal preparation. “Finished” might mean an approved proposal has been sent and recorded. Stopping the measurement at “draft written” would hide the approval queue and encourage writers to start new drafts while completed value waits.

A business process map can reveal these gaps. Include preparation, active work, review, waiting for external information, and completion. Do not create so many states that people cannot keep the board current.

Be explicit about the backlog. An idea or request that has not been accepted into active work is different from an item the team has promised to complete. Both may need prioritization, but counting them together obscures the commitment boundary.

Observe where work actually accumulates

Before selecting a limit, inspect recent work and the current queue. Where do items wait? Which skill, approval, machine, or external response constrains progress? Which items keep returning to an earlier step?

A full column can indicate a bottleneck, but it can also reflect an unusually large item or inconsistent updating. Read the records and talk with the people doing the work.

For a proposal team, writing may be fast while technical review is available only twice a week. Adding more writers could increase the review queue without increasing completed proposals. A limit can make that constraint visible, but the operating response may involve review availability, better input, or narrower proposal scope.

Use the workforce capacity planning guide to examine available skills and coverage. Headcount alone does not describe the capacity of a specialized step.

Set an initial limit as a hypothesis

Start with a limit that the team can explain from observed work and available capability. Avoid treating a number copied from another team's board as a universal formula.

The initial question is: with this much work active, can the team make useful progress on the oldest items while preserving review quality? If the answer is no, reduce concurrent commitments or repair the constraint. If the process repeatedly starves a capable downstream step, investigate whether the limit or the preparation policy is too restrictive.

Consider a limit for the whole active workflow as well as selected constrained stages. A limit only on “being written” may leave unlimited work waiting for review. The apparent control then moves the accumulation into a different column.

Publish the rule in plain language. People should know which items count, what happens when the limit is reached, and who can approve a temporary exception.

Work through a proposal queue

Imagine a small team with twelve proposals in progress: five being drafted, six awaiting technical review, and one ready to send. The team completes about four proposals in a typical week, with substantial variation. These figures are illustrative, not a benchmark.

The review queue is the obvious place to investigate. Some proposals may lack required information, while others simply await the same specialist. The team first separates those causes.

It then tries a total active limit of eight and a review-stage limit of three. Existing work is not deleted or relabeled to make the board look compliant. Instead, new commitments pause while the team sends the ready proposal, resolves missing inputs, and schedules review of the oldest usable drafts.

The first visible result may be fewer drafts started. That is expected. The useful questions are whether approved proposals reach customers more consistently, whether old items stop lingering, and whether the team avoids repeated rework.

Decide what to do when the limit is reached

A limit without a response policy becomes a colored warning everyone ignores. Define several appropriate actions:

Helping the constrained step does not mean asking unqualified people to approve technical work. They may assemble evidence, remove administrative friction, or prepare the next item so the specialist can focus on the decision.

The team can also use spare capacity for maintenance, training, or improving the workflow. Starting another customer commitment is not the only productive response to a full active queue.

Keep blocked items inside the story

A blocked item still occupies attention and often represents a promise. Removing it from WIP solely to permit more starts can make the process appear healthier than it is.

Mark the blocking reason, who can resolve it, and when the team will check again. Distinguish “waiting for customer dimensions” from “waiting for internal reviewer.” The remedies differ.

There may be legitimate rules for returning an item to an uncommitted state, such as a customer pausing a project for several months. Make that a clear business decision, including communication about the suspended commitment. Do not let operators quietly move difficult work backward to improve their numbers.

Track blocked age separately where useful. A queue containing many old external dependencies needs a different response from one with a temporary burst of active work.

Distinguish active attention from scheduled waiting

Some work includes a necessary waiting period, such as a customer reviewing a draft or a material completing a prescribed process. That waiting is different from an item nobody has time to handle. Show the distinction without declaring either item finished.

For the proposal team, a customer-review state might have a scheduled follow-up date and a separate capacity policy. The team still counts the open customer commitment, while recognizing that it does not require continuous writing effort. If the customer requests changes, the return path should be explicit so ten simultaneous revisions do not enter an already full drafting queue unnoticed.

This is also a reason to look beyond one board total. A stable total can contain a growing concentration of items about to return for intensive work. Upcoming decision dates and expected returns help the team anticipate that load.

Give urgent work a visible cost

Some work must interrupt the normal order. Define what qualifies and who decides. “A senior person asked” is an unreliable urgency rule because it can turn every request into an exception.

If an urgent item enters a full system, name the work it displaces or the additional capacity required. Communicate changed expectations to affected owners. An expedite lane does not create extra hours; it changes the order and distribution of delay.

Limit the exceptional path as well. Multiple simultaneous emergencies may require a broader incident or capacity decision rather than another special lane.

Review urgent items afterward. If the same avoidable cause repeatedly creates emergency work, repairing that cause may improve flow more than adjusting the ordinary WIP limit.

Avoid comparing unlike items carelessly

One proposal may require a standard price update while another involves a complex custom design. A simple item count can conceal a large difference in effort and uncertainty.

Where practical, break work into smaller outcomes that remain meaningful to the customer. Do not split one unfinished commitment into many trivial cards merely to increase the completion count.

For materially different work types, inspect them separately or use explicit policies for large items. Keep the method understandable. A complicated weighting system can become harder to maintain than the queue it describes.

Also preserve quality checks. Declaring work finished before review, acceptance, or required evidence may reduce measured WIP while increasing defects. The finish definition should survive pressure to make the chart look better.

Read several measures together

The Kanban Guide identifies WIP, throughput, work-item age, and cycle time as useful flow measures. For this business review, look at how many items are unfinished, how many finish over time, how old current items are, and how long completed items took.

Each measure has a limitation. Completed-item cycle time excludes work that is still stuck. Throughput can rise because the mix shifted toward simpler tasks. WIP can fall because demand fell or items were canceled.

Use the KPI dashboard guide to connect each measure to a decision. Display counts and context alongside trends rather than presenting one average as a complete performance verdict.

Include customer consequences, such as missed promised dates or repeated clarification. Faster internal movement is useful only if it contributes to a dependable outcome.

Review the limit without erasing its signal

Choose a review interval that allows enough representative work to pass through the system. Inspect specific blocked or aging items and compare the observed pattern with the hypothesis behind the limit.

If the team hits the limit regularly, do not raise it automatically. Ask whether the constraint is fixable, whether work is being accepted too early, or whether the demand exceeds available capacity.

A higher limit may sometimes be appropriate, such as when a new reviewer adds real capability or the workflow changes. Record the reason and watch the resulting behavior. A lower limit can also be appropriate when too many items remain partially attended.

Change one important policy at a time where feasible. Otherwise, the team may not know whether improved flow came from the limit, better preparation, or a change in demand.

Protect the demand conversation

A WIP limit can improve visibility while leaving a larger business mismatch unresolved. If qualified requests arrive faster than the team can sustainably complete them, the backlog will continue to grow.

The business then needs choices about service scope, lead times, pricing, staffing, scheduling, or demand acceptance. Do not ask the team to hide that mismatch by keeping every request nominally active.

Tell customers when work has been accepted and what evidence supports the expected timing. A transparent queue can be more trustworthy than an immediate “we have started” message followed by weeks of inactivity.

The operating value of a WIP limit is that it exposes these choices early. It gives the team a reason to finish, unblock, or renegotiate work before adding another commitment to a system that cannot yet absorb it.