Starting work feels productive. Finishing it often requires waiting, asking for help, or resolving an awkward problem. A work-in-progress limit changes the incentive: when the agreed number of active items has been reached, the team must address existing work before taking on another item.
Kanban's work-in-progress controls connect these limits to how work moves through a process. The limit might cover the whole workflow or a particular stage, such as review. It is not necessarily a cap on how much work each individual may touch.
A small support team could allow five active investigations. When all five slots are occupied, a free colleague might help reproduce an issue or obtain a missing answer rather than opening a sixth case. The constraint makes a bottleneck harder to hide behind new activity.
A limit that is routinely ignored is just decoration. A limit that cannot accommodate genuinely urgent exceptions can also become obstructive. Teams need a visible way to handle exceptions and change the limit as they learn. The purpose is a manageable flow of completed work, not achieving a particular number on a board regardless of what the work actually requires.
Real cases
- Cocoon Projects: contribution-weighted governance with LiquidO — Can open participation coexist with authority weighted by assessed contribution?