WIP limits: the one Kanban rule that actually speeds teams up

Teams adopt Kanban by drawing columns and stop there. The columns are decoration. The rule that changes throughput is the number written at the top of the column — the work-in-progress limit.

Why limiting work makes it faster

Little's Law: average cycle time equals average work in progress divided by average throughput. Throughput is bounded by your team's actual capacity, so if WIP doubles, cycle time doubles. Nothing gets done sooner because five things are in flight; they all just finish later, and each one accumulates more context-switching cost on the way.

The second effect is social. When a column is full, the person who would have started something new has to help finish something instead. That is the behaviour every "we need better collaboration" initiative is trying to buy, and a number in a column header buys it for free.

Picking the first limit

Start at number of people in that stage plus one. Four developers means an In Progress limit of five. Two reviewers means an In Review limit of three. It is deliberately slightly loose so the team meets it without gaming it, and you tighten later.

Then watch for a week. If the limit is never hit, it is too high to teach you anything. If it is hit constantly and work sits blocked, the bottleneck is downstream, not in that column.

The column that always needs a limit first

Review. Almost every team's real bottleneck is waiting for someone to look at finished work. Cap it at three or four and the effect appears within days: reviews get done before new work starts, and the average age of items in review collapses.

Four failure modes

• The parking lot. Teams invent a "Blocked" column outside the limits and park everything there. If blocked items do not count, you have no limit. Keep blocked work in its column with a flag.
• Per-person limits only. Useful, but they optimise individuals rather than flow. Use column limits as the primary constraint.
• Limits without a policy. Decide in advance what happens when the limit is hit. "Help the oldest item in the next column" is a good default. Without a policy, people just override.
• Counting tasks of wildly different sizes. If items range from an hour to three weeks, split the big ones. WIP limits assume roughly comparable units.

Measuring whether it worked

Track median cycle time and the 85th percentile weekly. The median tells you the typical case; the 85th percentile is what you should quote to stakeholders, because it is the number they will hold you to. If both fall over three or four weeks while throughput holds steady, the limits are doing their job. If throughput drops, you over-constrained — loosen by one and watch again.

---