Work in progress limit

A cap on how many items may be in progress at once, which forces work to be finished before anything new is started.

A work in progress limit is the control that a flow-based system uses in place of an iteration boundary. Set it low and a blockage becomes visible within hours, because nobody can start something else to stay busy, and the team is forced to clear the obstruction rather than route around it. Set it high, or leave it unset, and the board fills with items that are all technically started and none finished, which is the state that makes cycle time unpredictable. The limit is deliberately uncomfortable: the discomfort is the signal it exists to produce.

See also

Flow-based delivery

Work organised as a continuous pull with no fixed iteration, controlled instead by a limit on how much may be in progress at once.

The number of work items completed per unit of time, counted where work leaves the system rather than where it is started.

Where this comes up

Closing an agile project: ending work that could always run one more sprint

Predictive work gets an ending for free, the day the thing is handed over. Iterative work has to manufacture one, which is why so much of it never formally ends at all.

Delivery cadence: the rhythm you work to, and how often something actually ships

Cadence is the beat the work runs to. Delivery cadence is how often finished output reaches the people who asked for it. Teams conflate the two and then wonder why nobody feels the pace.

Iteration-based and flow-based agile: one fixes the interval, the other fixes the queue

Iteration-based agile fixes the length of the cycle and commits a batch to it. Flow-based agile fixes the amount of work in progress and pulls the next item when a slot frees.