Kanban WIP Limits: Finish More Before Starting More
TeamBoard Editorial
A busy board is not the same as steady delivery. Use a practical WIP policy to manage review queues, keep blockers visible, and decide when to start new work.
Your board has plenty of activity: drafts in progress, designs awaiting feedback, and another request arriving before lunch. Yet the same items remain open at the end of the week. Before asking people to start faster, look at how much work the team has already started.
Kanban WIP limits make that conversation concrete. A work-in-progress limit sets an explicit boundary on open work in a stage or across a workflow. It gives the team a shared reason to finish, review, or unblock something before pulling in another item.
Define the boundary before choosing a number
The Kanban Guide defines WIP as items that have started but have not finished. Your team needs a practical definition of both points. If acceptance is part of delivery, an item waiting for acceptance is still unfinished work.
For a creative team, “started” might mean that an agreed brief has entered production. “finished” might mean that the requested asset has passed review and been accepted. Ideas in an unstarted backlog sit outside that boundary. Make those rules visible so people count the same things.
Choose an experiment, not a universal formula
A limit is not automatically one task per person. Two people may collaborate on a single deliverable, while one reviewer supports several contributors. Availability, task size, specialist skills, and review schedules all affect what the team can handle.
Observe where work accumulates and which items wait longest.
Choose one congested stage for your first experiment.
Agree on an initial limit and the action to take when it is reached.
Set a review date that fits a representative period of work.
Check the work items themselves. Counting a complete campaign alongside a minor copy edit can conceal more than it explains. Break out independently reviewable deliverables where useful; do not split work merely to improve the count. Start with a clear task and acceptance condition.
A worked example: production outruns review
Imagine a small agency with a writer, a designer, and a reviewer. Its board has Ready, Production, Review, and Done. Four assets are waiting for review, but the team keeps starting new ones. More production increases the queue without resolving the approval delay.
As an illustrative experiment, the team chooses a limit of two items in Production and two in Review. These numbers are examples, not a benchmark. When Review reaches its limit, contributors help consolidate feedback, clarify an acceptance question, or prepare the oldest item for a decision before starting another asset.
If four items are already in Review, the team works down the queue. Moving two cards elsewhere simply to satisfy the displayed number would hide the problem. The rule should guide decisions, not encourage cosmetic changes to the board.
Write down what “full” means
A useful policy says more than “Review: 2.” For example: “When Review is full, check the oldest item, identify the decision it needs, and contact its reviewer before pulling new production work.” Name who handles follow-up and how the team will make exceptions.
Keep the rule short enough to use during a daily check. Review the right-hand side of the workflow first: what can be accepted, what needs a decision, and what is blocked? Then decide whether there is room to start something else.
Keep blocked and urgent work visible
A task waiting for a client remains an unfinished commitment. Record the dependency, the next action, its owner, and when to follow up. If the team genuinely cancels or returns work to an unstarted queue, record that decision explicitly rather than hiding it to create apparent capacity.
Urgent work needs an agreement too: what qualifies, who can authorize it, and which existing commitment may move. Log exceptions and discuss them at the review. Frequent emergencies may reveal a problem with intake or priorities that a higher limit will not solve.
Use the policy with a TeamBoard workflow
Use TeamBoard’s Kanban workflow guidance to agree on meaningful stages, owners, and completion conditions. Keep your WIP policy in a clear project note or linked document, and check the active cards against it. This is a team operating agreement; it does not depend on an automatic software cap.
Keep decisions and the reason for exceptions close to the task through team collaboration. A colleague returning after a day away should be able to see why an item is waiting and what happens next.
Review outcomes before changing the limit
Are items spending less time waiting in the stage you targeted?
Are accepted deliverables finishing regularly?
Are older and blocked items being noticed earlier?
How often is the limit exceeded, and why?
If no ready-made report exists, record start and finish dates for a small sample manually. Keep task size and changes in availability in view. A quieter week alone does not prove that the limit improved delivery. Change one policy at a time and record the reason.
Common questions
Does every column need its own limit?
No. Start with the constraint you need to understand. You might control one congested stage or total open work, provided the team knows what each boundary includes.
What if someone has nothing new to start?
Look for useful ways to unblock, review, or finish existing work. If none is available, discuss the dependency or skill constraint instead of automatically opening another item.
When should we increase the number?
When observation supports a change, such as a sustained change in capacity or delivery structure. Reaching the limit by itself is a prompt to inspect the workflow.