WIP Limits: The Kanban Rule That Speeds Teams Up

WIP limits (work-in-progress limits) cap how many items can sit in a stage of your workflow at once. If "Code review" has a limit of three and three cards are already there, nobody pulls a fourth in. Instead, they help clear what is stuck. It feels counter-intuitive: doing less at once is how teams deliver more.

Why less in progress means faster delivery

Every half-finished item costs something. It holds context in someone's head, it might go stale, and it hides how far from done you really are.

When a team starts everything and finishes little:

• Context switching eats the day. Five tickets in progress means four that are not getting attention.
• Queues grow invisibly. Work piles up waiting for review or testing, and nobody notices until the client asks.
• Lead time stretches. A ticket that needs two days of effort takes three weeks to ship because it spends most of its life waiting.

Limits make the queue visible and force the uncomfortable conversation: "we cannot start anything else until review clears."

How to set your first WIP limits

1. Start with your team size. For each column, set the limit near the number of people who work that stage. Four developers? Try four in "In progress".
2. Leave queue columns tight. "Ready for review" and "Ready for QA" are waiting rooms. Low limits stop them turning into warehouses.
3. Run it for two weeks. Do not tweak daily. Let the pressure show you where the real bottleneck is.
4. Adjust in the retrospective. If a limit is hit constantly and people sit idle, it may be too low. If it is never hit, it is too high to matter.

Running sprints right now? See how Flow handles boards, sprints and burndown together. Get started with Flow →

What to do when you hit a limit

This is where WIP limits pay off. When a column is full:

• Swarm. Developers who would start new work review or test instead.
• Pair on the blocker. If one card is stuck, two people often unstick it faster.
• Ask why. A column that is always full is your bottleneck. Maybe testing needs help, or stories are too big.

The rule of thumb: stop starting, start finishing.

Common objections

"We will have idle people." Rarely. There is almost always something to review, test or unblock. Idle time near a full column is a signal, not a waste.

"Urgent work does not fit." Agree an expedite lane with its own limit of one. Urgent work then has a path that does not blow up the rest of the board.

WIP limits in Trello and other board tools

Trello is wonderfully simple, and that simplicity is why many teams start their kanban board there. A common Trello habit is writing the limit into the list name, such as "Review (3)", and treating it as a team agreement. That convention works in any tool, because a WIP limit is ultimately a social contract the team keeps.

Where Flow fits

Flow does not try to replace that agreement, but it makes it easier to keep and to see when it slips.

• Custom columns. Rename, recolour and reorder columns to show each stage and its limit clearly, and use filters to see one person's cards at a glance.
• Person workload. See how much each person carries across projects before you hand them another ticket.
• My Work. In Livex Flow, everyone sees all their assigned work across projects in one view, which makes overcommitment hard to miss.
• Project health. Health findings link to the exact tickets behind a problem, so stuck work does not hide. Read more on workload management.