work in progress limit
Also called: WIP limit, work-in-progress limit
A cap on how many tasks a person or a column of the task board may have started but not finished. Starting less makes work finish sooner and shows where it piles up.
A work in progress (WIP) limit caps how many tasks a person, or a column on the task board, may have started but not finished. When the limit is reached, nobody starts anything new; they help finish what is already in progress, or clear the column that is blocking it.
The reason is arithmetic, not discipline. Over a stable period, the average time a task spends in progress roughly equals the number of tasks in progress divided by how many get finished per unit of time (a well-established result from queueing theory). If a team finishes about the same amount per week either way, more items in progress simply means each one takes longer to finish. Six half-done tasks deliver nothing; two finished ones deliver two. Switching between many tasks also costs time on its own.
The second benefit is visibility. A column that hits its limit shows where work piles up: a review step, a single expert, a waiting-for-supplier queue. Without limits, the pile-up hides inside everyone's "doing" list until a deadline exposes it.
Set limits low enough to bite and adjust them by observation: a common start is one or two items per person in "doing" and a small number for shared steps like review. The limit is a signal, not a rule to game: raising it every time it is reached hides the bottleneck it was meant to reveal.
Example
January 2027, the last four weeks before Klasna's physics opening on 1 February. The team's board has five columns: to do, doing, waiting, review, done. Danylo has six cards in "doing" and none finished. The team sets limits: 2 cards in "doing" per person and 3 in Vira's "review".
On Wednesday the review column holds 5 practice sets, two over its limit, while two tutors have just finished their own cards. Instead of each starting a new set (which would only queue behind review), they help clear it: they solve the sample tasks of the waiting sets, so Vira's check is faster.
Why it matters, with an illustrative assumption: if Vira clears about 1 set a day, a set entering a queue of 5 waits about 5 ÷ 1 = 5 working days to come out of review; with the queue held at 3, about 3 days. Over the 4 one-week iterations from 4 to 29 January, that difference decides whether the last topics are checked before the opening or after it. The limit didn't make Vira faster; it stopped new work from piling up in front of her.
Common mistakes
- Counting "busy" as progress. Many started tasks look productive and finish late; count what reaches "done".
- Raising the limit when it is reached. That hides the bottleneck the limit exists to show.
- Starting new work when blocked. Help finish or unblock instead; new cards only join the queue.
- Limits only on people, not on shared steps. Review, approval and supplier queues are where work usually piles up.
- Setting limits so high they never bite. A limit that is never reached changes nothing.
Learn it in the course
- A fixed date with weekly iterations · Keep the exam date and a few milestones fixed, let scope flex, and run the last weeks in short iterations with a board, limits on work in progress and a weekly demo of working pieces.