Pull up almost any small team's board midweek and the shape is familiar: a full backlog column, two or three cards finished, and one card parked in "In Review" with no comments on it. The instinct is to read that as a people problem — someone's slow, someone's distracted. It's usually not. It's a queue, and nobody put a cap on it.
The column is the problem, not the person
Work in progress (WIP) is just the set of tasks a team has started but not finished. Every column on a Kanban board — In Progress, Review, QA, whatever your team calls it — is a queue, and every queue without a limit will fill up until something downstream can clear it. That's not a motivation failure. It's basic queueing behavior: the moment arrivals into a stage outnumber what that stage can finish, the queue grows, and it keeps growing right up until someone notices and asks why nothing's "done."
A WIP limit forces the opposite question earlier. Instead of letting five tasks pile into Review and asking in the retro why review takes so long, a limit of two means the fifth task can't even start until one of the first two clears. The backlog waits. The bottleneck becomes visible immediately, on the board, instead of three days later in a status update.
How to size your first WIP limit
Most teams either skip WIP limits entirely or guess at a number that's really just "however many people we have." Neither works. A limit that's too loose doesn't change anything; a limit that's too tight stalls the board on day one. A better starting point:
1. Look back at your last 2-3 sprints. Count the highest number of cards that were sitting in each column at the same time — not how many moved through, how many were open simultaneously.
2. Subtract one from that peak. That's your starting limit for that column. It should feel slightly uncomfortable, not impossible.
3. Run it for one sprint before changing it. The first week will surface exactly which column is the real constraint — usually not the one anyone expected.
4. When a column hits its limit, stop starting new work there and go finish what's already in it. That's the whole mechanism. The limit only works if the team actually honors the stop.
Set the limit per column, not per person and not per sprint. A sprint-level WIP cap tells you nothing about where work is actually stuck; a column-level cap points right at it.
> A WIP limit doesn't make a team move faster. It makes the bottleneck that was already there impossible to ignore.
Where this actually bites: Review and QA, not Backlog
The column that needs a limit almost never shows up where people expect. Backlog can hold fifty cards and it's fine — nothing's "in progress" yet, it's just unstarted work. The columns worth capping are the ones with a human gate: code review waiting on one senior engineer, QA waiting on the one person who knows the test environment, "Waiting on client" waiting on someone outside the team entirely. Those are the stages where work arrives faster than it clears, and they're exactly the stages a sprint board tends to undercount because the cards still look "in progress" even while nothing is actually happening to them.
What this looks like on a real board
Spryn's Kanban board sets WIP limits per column, not globally — so "In Progress" might cap at 3 while "Review" caps at 2, matching wherever the team's actual bottleneck sits. When a column is full, the board makes that visible instead of letting a sixth card quietly join the pile. Combined with the AI standup summary, which pulls blockers and action items out of what the team actually typed that morning, a stuck card in a capped column gets flagged the same day instead of surfacing for the first time at the sprint retro.
None of that requires a separate tool from sprint planning — it's the same board the team already plans sprints on, which matters for a small team that doesn't have a dedicated flow-metrics dashboard.
When a WIP limit won't fix anything
Worth saying plainly: a WIP limit exposes a bottleneck, it doesn't resolve one. If "Review" is capped at 2 and both slots are permanently full because there's exactly one person who reviews code, the limit will correctly show you that problem every single day — but the fix is adding a second reviewer or cross-training someone, not adjusting the number. Teams that treat the WIP limit itself as the fix usually end up quietly raising it every time it gets in the way, which just rebuilds the queue they were trying to see in the first place.
A WIP limit's job is to make the real constraint undeniable. What the team does about that constraint is a separate decision — and usually a more useful one than anything the number itself can tell you.
---
Self-hosted teams running Spryn get this on the same board they already use for sprint planning — see spryn.io/pricing for the one-time license, or spryn.io/product/features for the full capability list.