A work-in-progress limit caps started but unfinished work so people can finish and unblock existing commitments. Keep incoming demand visible in a separate queue, define what counts as started and agree how urgent exceptions displace other work. Review flow and customer impact rather than rewarding relabelled tasks.
Define the unit and the boundary
Choose the part of the workflow the limit will govern and a unit that people can recognise. A project may be too large if one project contains many independent deliverables; tiny tasks may hide substantial coordination. Start with a useful delivery item that has an observable acceptance condition. Define when it starts and when it is genuinely finished, including required review rather than only the production step.
Count blocked items inside work in progress when they still consume attention or hold a commitment. Otherwise moving every inconvenient item into a waiting column makes the limit cosmetic. Keep the blocker and next action visible. Distinguish work that has not started from work paused after effort has already been invested. This distinction helps the team understand both demand and the cost of returning to unfinished commitments later.
Create a pull rule and an honest intake queue
List incoming requests without implying they have all been accepted for immediate delivery. Record their need, owner, timing and decision status. Agree who chooses the next item when capacity opens. The team should be able to explain why a request is waiting and what review it will receive, rather than treating the limit as a reason to ignore customers. Show dates promised elsewhere so queue decisions account for existing obligations.
When the limit is reached, ask how people can help finish, review or unblock current items before starting another. Some skills may not transfer easily, so use judgment rather than forcing unqualified assistance. Define an urgent exception route with an approving owner. An expedited item still uses capacity; record which work is displaced and who needs to know. Avoid allowing every influential requester to bypass the rule privately.
Trial the limit and inspect the consequences
Choose an initial limit as a hypothesis, not a universal law. Review the number of completed items, time in progress, blocked age, quality issues and the incoming queue over a defined period. Compare similar work and note demand changes. A lower count of active items is not success if accepted deadlines fail because no one handles a genuine dependency. Ask staff and customer-facing owners what the trial makes easier or harder.
Adjust the boundary or limit when evidence supports a change. Preserve the reason and date so colleagues understand the operating rule. Resist increasing the limit simply because a queue is uncomfortable; first inspect why work is not finishing. Equally, do not defend a limit that consistently prevents sensible action. The goal is a manageable flow of completed customer value, with demand and trade-offs visible.
Keep records at the level necessary for coordination rather than surveillance. A work-in-progress board should show work state, blockers and ownership, not become a contest over individual activity. When a person helps resolve another item, acknowledge the completed flow rather than penalising them for starting fewer personal tasks. The measurement system should support the behaviour the limit is intended to encourage.
Fictional worked example
A fictional scenario to explain the method, not a customer result or a market benchmark.
The fictional team Harbor Craft has twelve active delivery items and frequent context switching. It trials a limit of six started items, including blocked ones, while keeping all new requests in an intake queue. A review owner selects the next item only when an existing one reaches acceptance. The team does not erase previously started work to make the board fit the new rule.
An urgent customer correction arrives during the trial. The authorised lead accepts it, identifies which planned item will move and informs the affected customer owner. At cutoff, Harbor Craft reviews completions, blocking and missed commitments rather than announcing success because the board looks smaller. These invented circumstances demonstrate a transparent limit and exception process without claiming a guaranteed cycle-time improvement.
TAKE THIS INTO YOUR NEXT CONVERSATION
A practical next-step checklist.
- Define started, blocked and accepted completion states.
- Keep incoming requests visible outside the active limit.
- Require an explicit urgency trade-off and owner.
- Review flow, quality and customer impact after a trial.
Common questions.
Do blocked items count toward the limit?
Usually yes when they remain started commitments. Show the blocker and owner so the team can help resolve it instead of hiding it outside the count.
What if a specialist has nothing useful to do?
Examine preparation, cross-training or future risk reduction without manufacturing started delivery work. Do not require unqualified help merely to make everyone appear equally occupied.
Further reading & source context.
These primary references provide background. They are not evidence for the fictional example above and do not endorse AccelerateLink.
Found an error or a missing qualification? Send an editorial correction.
Find my next move.
Use a practical tool to turn this idea into a clearer starting point.
Find my next move