Set Work-in-Progress Limits That Reduce Waiting
Introduce work-in-progress limits with explicit exceptions and team policies, using a review bottleneck example to improve flow without gaming the board.
Count work that has started but is unfinished
Work in progress includes items waiting for review, blocked by a dependency, or awaiting a final check after implementation. Hiding those items in a parking column does not remove their demand on the team. Define where work starts and finishes, then inspect the amount between those points. A limit is useful when it changes behavior toward finishing and unblocking, not merely when it creates a number on the board.
Find the queue that grows repeatedly
In a hypothetical team, developers start new items while six completed changes wait for one reviewer. Starting more development increases the review queue without increasing delivery. Discuss what help the reviewer needs: smaller changes, shared review skills, clearer acceptance criteria, or scheduled attention. A limit should expose that constraint and encourage collaboration. It should not become a rule that leaves people idle while avoidable waiting continues.
Choose an initial limit as an experiment
Agree a limit the team can explain from its current capacity and workflow. There is no universally correct number of items per person. Include a policy for urgent work and make exceptions visible rather than quietly bypassing the limit. Record why an exception was accepted and which work was displaced. The team working-agreement guide helps turn the number into a shared operating policy.
Measure finishing, not board compliance
Track item age, completion rate, and time spent waiting alongside the limit. If the team splits tickets only to keep counts low, the measure has stopped representing real work. Check whether customers receive useful changes sooner and whether quality remains acceptable. Use the agile metrics guide to interpret flow evidence, and inspect individual old items rather than relying only on an average.
Review and adjust the policy
After several comparable working periods, ask what the limit revealed and whether the team changed its behavior. A persistent blocked item may need a dependency decision, not a higher limit. A newly cross-trained reviewer may justify changing the policy. Keep the experiment small enough to learn from. Capture the result in a retrospective experiment, including the conditions under which the team would revise the limit again.
Published by AgilePro.info under our Editorial Policy. Guidance is based on established delivery practice and is general information, not professional advice for a specific project.