WIP Limits Are the Kanban Practice Teams Skip and the One That Does the Work
Most teams that say they use Kanban have a board. Columns for To Do, In Progress, Review and Done, cards moving left to right, maybe a swimlane for urgent work. What most of them don’t have is a work in progress limit on any column. Without one, the board is a status display. It shows the work. It doesn’t change how the work flows.
A WIP limit is a cap on how many items can sit in a column at once. If In Progress has a limit of four and four cards are already there, nobody pulls a fifth. They help finish one of the four instead. That single rule is what turns a board into a pull system, and it’s the part teams quietly drop because it feels like it slows them down.
Why starting more feels productive and isn’t
Every developer knows the pattern. A ticket gets blocked waiting for a review or an answer from product. Rather than sit idle, the developer starts another ticket. Then another. By Thursday the team has eleven items in progress, three in review, and nothing in Done since Monday.
Everyone was busy. Little shipped. The reason is a simple relationship known as Little’s Law: average time in the system equals the amount of work in progress divided by throughput. If a team finishes about five items a week and keeps fifteen in progress, each item takes around three weeks from start to finish. Cut the in-progress count to eight at the same throughput and the average drops to under two weeks. Nothing about the code got faster. The queue got shorter.
Long cycle times cost more than patience. Work that sits half-finished goes stale. Branches drift from main and merge conflicts pile up. Context switching between five open tickets eats hours nobody tracks. And feedback from users arrives weeks after the developer has moved on, when fixing what they learned is most expensive.
What the limit actually forces
The value of a WIP limit is in the moments it hurts. When the In Progress column is full and a developer is free, the rule says: don’t start something new, go help. Review a pull request. Pair on the blocked ticket. Chase the product question that’s holding a card up. Write the missing test.
That’s the behavior change. The limit moves attention from starting to finishing, and it makes bottlenecks visible. If the Review column is always full and In Progress keeps getting stuck behind it, the team has a review problem, not a coding problem. Without limits, that same bottleneck hides behind a long list of busy-looking cards.
It also changes how standups sound. Instead of each person reporting what they did, the team walks the board from right to left and asks what it takes to move the item closest to Done.
Setting the first limits
Start from what the team does now, not from a formula. Count how many items are in each column on a normal day, then set the limit a little below that. A common starting point for In Progress is about one item per developer, or slightly fewer, so that pairing and swarming become the natural response to a full column.
Put limits on review and testing columns too. That’s where work most often piles up in AI-heavy teams, where coding agents can open pull requests far faster than humans can review them. A review column with a limit of three makes the team stop generating code and start reading it.
Expect the limits to feel wrong for two or three weeks. People will want exceptions. Allow a clearly marked expedite lane for genuine production incidents, with a limit of one, and resist every other exception. Review the limits at the retrospective and adjust them by one at a time.
What to measure
Two numbers tell you whether limits are working: cycle time per item and throughput per week. Cycle time should fall and become more predictable. Throughput usually holds steady or rises slightly. If throughput falls hard, the limits are probably too tight, or a single bottleneck is starving the rest of the board.
None of this depends on whether the team calls itself Kanban or Scrum. As we’ve argued before, that choice is usually the wrong question. A Scrum team that caps work in progress inside the sprint gets the same benefit. The board was never the point. The limit is.