What it means
Work-in-progress limits constrain how many items can occupy defined workflow states so teams finish work, expose bottlenecks, and reduce delay.
Why it matters
Starting more work can make everyone busy while increasing queues, context switching, aging, and the time required to deliver any one item.
Practical focus
- Set explicit limits for workflow states and define what counts as entering or leaving each state.
- Treat a reached limit as a signal to finish, unblock, or improve flow rather than bypass the policy.
- Adjust limits using observed service level, bottlenecks, variability, and team capacity.
- Retain the approved definitions, assumptions, decisions, ownership, exceptions, measures, and change history that demonstrate how Work-in-Progress Limits operates in real project work.
- Exercise this failure scenario: Teams continue starting new items while review is overloaded, producing a large queue of aging work and late discovery of defects.
Common mistakes
- Using Work-in-Progress Limits as a label without defining its scope, owner, decision criteria, and expected evidence.
- Treating a template, meeting, tool screen, or status report as proof that Work-in-Progress Limits works consistently in normal delivery.
- Optimizing a single activity while ignoring dependencies, incentives, risk transfer, and the end-to-end outcome.
- Testing only the expected path and never rehearsing this failure condition: Teams continue starting new items while review is overloaded, producing a large queue of aging work and late discovery of defects.
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: