Set a WIP limit your team can actually use

Read the diagram as text

The example board limits Doing to three items and Review to two. Review is full, so the team helps finish existing work before pulling another item. Choose real limits from the team’s observations.

Begin with a work item that has waited longer than anybody expected. Ask where it is, what it needs next and who can help it move. That conversation is a better starting point than selecting a fashionable number for every column. A useful work-in-progress limit changes a decision: when the system is full, the team helps finish work before admitting more.

Choose the boundary before the number

Use the same meaning of “started” and “finished” for your board and measurements. If an item is under review, waiting for testing or blocked by another department, decide explicitly whether it remains inside your system. Moving it to an uncounted parking column would make the board look tidier while leaving the customer's wait unchanged. The Kanban Guide treats work between the defined start and finish as WIP. Your boundary should make that definition useful for the service you deliver.

Write the boundary above the board. For example: “Started means accepted into implementation. Finished means the change is released and the acceptance checks have passed.” This is an illustrative working agreement, not a universal software definition. A support team or design service will need different words.

Run a small, reversible trial

1. Observe: record active items and completed items using one consistent unit.
2. Agree: select an initial cap that requires a meaningful conversation about starting work. Record why you chose it.
3. Respond: decide what happens when the cap is reached: review, pair, test or resolve a dependency.
4. Document exceptions: record the reason, owner and expiry for a genuine emergency.
5. Review: compare the waiting experience, delivery and quality before changing the policy.

A worked decision, not a performance promise

Imagine a team with twelve active changes. Four are awaiting review and two depend on an external decision. Setting an illustrative cap of ten does not make two items disappear. The first decision is to stop taking ordinary new work and identify a reviewer for the oldest ready change. The team then asks the dependency owner for a decision date. Keep the blocked changes visible; separately label their impediment so people can understand why they are aging.

Do not assume that a lower cap will automatically increase throughput. Work size, skills, demand and interruptions may change at the same time. Our flow calculator holds throughput fixed to illustrate a relationship; it does not forecast an individual team's delivery.

Keep the review honest

Bring the item history to the review, including unfinished and cancelled items. Ask whether people could apply the policy, whether an exception became routine, and whether customers received something useful. If urgent requests displaced planned work, discuss that trade-off openly. Record one policy change at a time where practical, along with the context needed to interpret its effect.

Working agreement to copy

Boundary: accepted for implementation → released and accepted
Initial cap: ____ active items
At capacity: ____ before starting ordinary work
Blocked-item owner and next review: ____
Exception reason / owner / expiry: ____
Review date and evidence to bring: ____

A cap is a guardrail for a conversation. Keep it legible, change it when evidence warrants and avoid treating “full” as the desired state. Read the historical Pull Systems essay for the earlier explanation that informs this experiment.