Your board has forty cards in the "In Progress" column and nothing shipped this week. Everyone is busy. Everyone is blocked. Every card is at 80%, which — as the old joke goes — means the whole thing is at 80% forever.
This is the failure a work-in-progress limit is supposed to prevent, and most teams technically have one. It's written in a wiki nobody reads, or it's a soft suggestion the board doesn't enforce, or it's set so high it never triggers. A WIP limit that never stops you from starting new work isn't a limit — it's a decoration.
The idea is almost embarrassingly simple: cap how many things can be in progress at once, and finish something before you start the next. The hard part isn't the concept. It's picking a number that bites, and then actually respecting it when the board turns red. Let's do both.
What a WIP limit is really for
The point of limiting work in progress is not to make people do less. It's to make the cost of context-switching and half-finished work visible, and to force the team to fix flow instead of hiding the problem behind everyone looking busy.
Three things happen when in-progress work is uncapped:
- Cycle time explodes. Ten tickets started in parallel all finish later than five started in sequence, because each one keeps getting paused for the next. Little's Law is not optional: the more work in flight, the longer each item sits.
- Blockers go unnoticed. When you can always start something new, a blocked ticket just gets quietly parked. Nobody feels the pain of it, so nobody clears it. A WIP limit turns that blocker into a wall — you can't start new work, so the blocker becomes the most important thing in the room.
- Reviews and handoffs starve. Starting is fun; finishing is chores. Without a cap, code review, QA and deploy columns fill up while everyone keeps pulling fresh work from the backlog.
A WIP limit is a forcing function. It converts "we should really finish things" from a good intention into a rule the board enforces on the team's behalf.
Why yours doesn't work
If you've set WIP limits and nothing changed, it's almost certainly one of these:
- The number is too high. A five-person team with a WIP limit of 15 has no limit. If the cap is larger than the team could ever hit, it never triggers. Start low enough that it hurts a little.
- The board doesn't enforce it. A limit that lives in a Confluence page is a suggestion. It has to be on the board, in the column, flagging overload the moment you cross it — otherwise the busy-brain default wins every time.
- You limit the wrong column. Capping "In Progress" but leaving "In Review" and "Ready to Deploy" unlimited just moves the pile-up one column to the right. Bottlenecks form at handoffs.
- You blink when it turns red. The first time the limit blocks someone and a manager says "just start it anyway, we'll sort it out," the limit is dead. The whole value is in not starting.
Notice that only the first is about the number. The other three are about discipline and where you put the cap. The tool can help with all of them, but it can't make you honor a red column — that part is culture.
Picking a number that holds
There's no universal right answer, but there's a reliable starting point. A common rule of thumb is roughly one to two items in progress per person, then tighten from there.
| Team size | Starting "In Progress" cap | Rationale |
|---|---|---|
| 3 people | 3–4 | Everyone owns one thing; one card of slack for pairing or a quick swap. |
| 5 people | 5–6 | One each, plus room for a review-in-flight. |
| 8 people | 8–10 | Above this, split into swimlanes per sub-team and cap each lane. |
Set it, run two weeks, and watch what happens. If the column never goes red, lower it — an untriggered limit is teaching you nothing. If it's red constantly and work genuinely can't flow, you've either found a real bottleneck to fix or the cap is a touch too tight. Adjust by one and try again. WIP limits are a dial, not a switch.
And don't cap only the middle. Put a limit on your review and QA columns too — often those are where flow actually dies. If "In Review" is permanently full, no amount of limiting "In Progress" will help; the constraint is reviewer time, and the red column is what makes that undeniable.
Making the limit stick in your.team
This is exactly the behaviour Kanban Boards are built for, so it's a concrete example of the mechanics that make a limit real instead of aspirational:
- The cap lives on the column. Set a work-in-progress limit per column directly on the board. When a column hits its cap, the board flags the overload — the signal is right where the work is, not buried in a doc.
- Columns are real statuses. Each column maps to an actual workflow status, so a drag is a real transition, not a cosmetic move. The limit governs genuine state, which means the number reflects reality.
- Swimlanes let you cap per lane. Group cards by assignee, epic or priority into swimlanes and keep a busy board legible — so an eight-person board can carry separate limits per sub-team instead of one blunt cap.
- Time is attached to every card. Because hours ride along on each card, a card that's been "in progress" for three days with twenty minutes of tracked time is visible as the stall it is — the board doubles as honest reporting.
The board being keyboard-first matters here too: when moving a card and clearing a blocker is a keystroke rather than a drag-and-dialog ceremony, people actually keep the board current, which is the whole precondition for a limit to mean anything.
The habit that makes it work
Tools set the ceiling; the team sets the norm. The one habit that turns a WIP limit from theatre into flow is this: when the column is full, don't start — swarm. Instead of pulling a new card, the person who's free helps finish or unblock a card already in flight. Pairing on the blocker, picking up the review, chasing the dependency — anything but adding to the pile.
That's the muscle. The red column isn't a nuisance to route around; it's the team's cue to converge on finishing. Do that for a few sprints and cycle time drops without anyone working harder — you're just working on fewer things at once, which was the entire point.
Start small, put the number where it hurts a little, and hold the line the first time it turns red. If you want the limit enforced on the board instead of living in a wiki, Kanban Boards are included on every your.team plan — set your first WIP limit at app.your.team/signup and see which column goes red first.
