Team Operations
Work-in-Progress Limits: Finish More Before Starting More
Define work in progress and test a sensible limit with an original flow exercise, while keeping blocked work and exceptions visible.
What you will learn
- Define started and finished work before choosing a WIP limit
- Use a simple flow ledger to reconcile starts, finishes and unfinished work
- Handle blocked items and urgent exceptions without hiding capacity pressure
A work-in-progress limit is an agreed constraint on how much started, unfinished work a team carries in a defined part of its workflow. It makes a capacity decision visible: when the limit is reached, help existing work move or explicitly resolve the exception before starting more.
A limit is not a productivity guarantee or a measure of individual effort. Its value is that it exposes trade-offs that an unlimited to-do list can hide.
What is a WIP limit?
First define the work item, where it starts and what counts as finished. The Kanban Guide treats work between defined start and finish points as work in progress and requires an explicit approach to controlling it. Your team's boundary should be clear enough that two people count the same items.
For a fictional content team, an item might be one approved article assignment. “Started” means drafting has begun; “finished” means the agreed editorial and production checks are complete. An article waiting for review remains unfinished even if its writer has moved on.
A backlog item is not automatically WIP. Neither is every idea mentioned in a meeting. Keep the queue separate from commitments so the team can see what it is actually carrying.
Work through the flow ledger
This original fictional exercise starts with four unfinished items and uses a team-wide limit of four. The number is an example, not a recommended cap for every team.
| Day | Finishes | New starts | Unfinished at day end |
|---|---|---|---|
| Monday | 1 | 1 | 4 − 1 + 1 = 4 |
| Tuesday | 0 | 0 | 4 − 0 + 0 = 4 |
| Wednesday | 2 | 1 | 4 − 2 + 1 = 3 |
Across the three days, three items finish and two start, leaving three unfinished. On Tuesday, the team does not create the appearance of progress by starting two more items. It investigates why existing work is stuck and whether someone can help with review or an unresolved dependency.
The ledger does not prove the limit caused better delivery. It simply makes starts, finishes and unfinished commitments reconcile. Compare actual behavior and outcomes during a bounded experiment before drawing a conclusion.
Count blocked work honestly
If an article is waiting for an authorized reviewer, it remains WIP under this example's definition. Moving it to a column labeled “waiting” should not make it disappear from the team-wide count.
Show the blocker, responsible owner and next review point. Some teams use separate limits for different workflow states; that can be useful when definitions remain explicit. Do not use an unlimited waiting column as a hidden storage area for abandoned commitments.
When the team cannot move an item, decide whether to pause or cancel it explicitly. Preserve the reason and any dependency that must be revisited. A cancellation is a valid decision, not a completion disguised by a status change.
Choose a starting limit as an experiment
Observe the current flow, item sizes and common bottlenecks. Select a limit the team can discuss and test, then define how long to observe it and what evidence to review. There is no universally correct number derived from headcount alone.
Watch item age, completed work, quality issues and the experience of people waiting for output. If the limit merely creates more unrecorded side work, investigate the policy and incentives. If everything is blocked by one scarce review capability, changing a number alone will not remove that dependency.
The task management guide helps clarify the underlying work, while the project management guide covers broader coordination. A WIP limit is a narrow operating policy within that system.
Make exceptions explicit
An urgent customer issue may justify interrupting planned work. Name who can authorize the exception, what enters and which commitment pauses. Record the decision rather than pretending the original capacity plan still holds.
Review repeated emergencies. If every new request is exempt, the limit is decorative. A useful policy makes the cost of changing priorities discussable without blaming the person who raised the need.
Copyable AI prompt
Try this with Aurora AI in Finta, Codex, or Claude, using authorized work records.
Review [workflow], [start and finish rules] and [work-item ledger]. Calculate WIP as started but unfinished items, including blocked work under the stated boundary. Reconcile beginning WIP plus starts minus finishes. Identify bottlenecks, hidden waiting queues and exceptions. Propose a bounded limit experiment with review measures, not a universal cap or output promise. Do not invent completions, cancel work or change team priorities without human approval.Make room to finish
Explore Finta's Process Simplification Advisor for the next workflow review. Start with visible commitments and a clear finish, then adjust the policy based on what the team actually learns.