Setting WIP limits is, for me, one of the least glamorous and at the same time most effective levers a team has. The idea fits into one sentence: you agree how many tasks may be in progress at once, and you only start something new when something else is finished. Sounds trivial. In practice, this single rule touches almost everything a team usually leaves unsaid: priorities, specialist knowledge, ownership and the question of who is actually allowed to say “no”.
I care about this topic because a full board looks so reassuring. Lots of work in progress feels like lots of progress. Often it is the opposite: every extra task stretches the waiting time of all the others, and at the end of the month a lot has been started and little has shipped. In this guide I show you how to arrive at sensible limits with your team in five steps, what to do when a limit is reached, and which mistakes are common.
In short
A WIP limit caps how many tasks a team works on at the same time. Less parallel work shortens cycle time because each task spends less time waiting – that follows directly from Little’s Law. The biggest pitfall is the rule behind the number: a limit only works if the team really stops starting and finishes together once it is reached.
What you will learn in this article
- What a WIP limit is and why it shortens cycle time
- How to find a first starting value for your board in five steps
- What the team actually does when a column is full
- Which four flow metrics help you fine-tune your limits
- Which mistakes to avoid as a team lead
What is a WIP limit?
WIP stands for “work in progress”: work that has been started but not yet finished. A WIP limit is an upper bound for exactly that work. You can set it for the whole board, for individual columns or for both. If the “In progress” column shows a 4 and four tickets are already sitting there, nobody pulls in a fifth one. Instead, someone helps to finish one of the four.
By the way, the current Kanban Guide (version 2025.5) does not use the term “WIP limit” at all. It says more generally that a team has to deliberately control the amount of work between start and finish. How it does that is described in its Definition of Workflow – the shared, explicitly written-down agreement on how work flows through the team. A fixed number per column is therefore one option among several. For getting started, though, it is the easiest to understand, so that is what this guide focuses on.
Much more important than the number is the principle behind it. A WIP limit turns a push system into a pull system. Work is no longer pushed into the team as soon as anyone has an idea. The team pulls new work when it has capacity, and the board makes that capacity visible to everyone.
Why setting WIP limits pays off
At the core is a relationship from queueing theory that John Little proved in 1961. Little’s Law reads L = λ × W. Applied to a team, it means: the average amount of work in progress equals throughput multiplied by the average cycle time. Rearrange the formula for time and it becomes tangible:
Cycle time ≈ WIP ÷ throughput
Take a fictional team building an app for a bike rental shop. On average it has twelve tickets in progress at the same time and finishes six per week. So a ticket needs roughly two weeks from start to “Done”. If the team cuts parallel work down to six tickets and still finishes six per week, the average cycle time drops to about one week. Nobody typed any faster. The tickets simply spent less time lying around.
An honest caveat: Little’s Law holds for long-term averages in a stable system. It is no good for forecasting next week. If your team keeps taking on more work than it finishes, the precondition is even violated. As a mental model it is still worth its weight in gold, because it clears up a stubborn misconception: starting more things at once makes nobody faster.
Less context switching
On top of that, the number of context switches goes down. Anyone with three tickets open in parallel jumps back and forth between them, loses the thread every time and has to keep more details in their head at once. That costs focus, even if it feels like diligence. With a limit, each person usually works on one thing and sees it through.
Bottlenecks become visible
The most underrated argument: a limit shows you where things get stuck. If the “Review” column fills up while “In progress” still has room, the bottleneck is in reviewing, not in development. Without a limit you hardly notice. People simply keep developing, and reviews quietly pile up in the background until someone asks why nothing has gone live for two weeks.
The full Review column shows the bottleneck: the team helps there instead of starting new work.
Setting WIP limits in five steps
Before you start setting WIP limits, you need three things: a board (a whiteboard, Jira, GitHub Projects or another tool), a team that is willing to give it a try, and two to four weeks of patience. A limit imposed by the manager rarely lasts. A limit the team proposed itself is one it will also defend.
Step 1: Make the workflow visible
First, agree on when a task counts as “started” and when it counts as “done”. Everything in between is WIP. Your columns should reflect the states your work really goes through, for example “Ready”, “In progress”, “Review”, “Test” and “Done”. Less is more here. Every extra column is one more place where work can wait, and one more limit that needs looking after.
Step 2: Measure where you are
For two weeks, count every day how many tickets sit in each column and note the numbers in a simple spreadsheet. It takes one minute a day. Pay special attention to invisible work: support requests via chat, favours done “real quick”, operations tasks. If that kind of work never shows up on the board, you will later be calculating with the wrong numbers. So add it as tickets of its own.
Step 3: Pick a starting value
Anyone setting WIP limits for the first time tends to look for the one correct number. It does not exist. A good first value sits slightly below your measured average. It should be noticeable without paralysing the team. For the “In progress” column, a useful rule of thumb is to stay below team size so there is room for reviews and pairing. Atlassian describes exactly this approach. The table shows a possible start for a fictional team of five.
| Column | WIP limit | Why this value |
|---|---|---|
| Ready | 6 | Enough choice for about a week without planning too far ahead |
| In progress | 4 | Below team size, so there is time for reviews and pairing |
| Review | 2 | Open reviews get done before anything new starts |
| Test | 2 | Bottlenecks in acceptance show up early |
| Done | – | Nothing happens afterwards, so a limit would be pointless |
| Expedite lane | 1 | For real emergencies that may overtake everything else |
Step 4: Agree on the ground rules
The number alone is worthless without rules everyone knows. Settle at least three points and write them down next to the board. First: blocked tickets count, because they still occupy a slot. Second: the expedite lane is reserved for real emergencies, such as a production bug, and has a limit of one. Third: what happens when a column is full? The answer follows in the next section.
Step 5: Observe and adjust
Give the new limits a few weeks before you change them. In the beginning it feels unfamiliar, and that is exactly the point. Look at the numbers together in your retrospective. If a limit is broken all the time, either the value is too tight or there is a problem in the process. Investigate the cause first. Only raise a limit when you have gained real capacity, for example because more people on the team can now do reviews.
What to do when the WIP limit is reached
This is where it gets decided whether WIP limits work or just sit decoratively above the columns. The rule is easy to remember: stop starting, start finishing. Whoever is not allowed to pull anything new looks to the right of the board. Is there a review I can help with? A test I can take over? A blocker I can resolve?
Read the board from right to left in the daily
A small change to the daily helps a lot. Instead of going round and reporting what everyone did yesterday, you walk the board from “Done” to the left. You can use these questions as they are, whether you meet in person or run an async daily:
- What is closest to “Done”, and what is still missing?
- Which ticket has been in progress the longest, and why?
- Which column is full, and who can help there today?
- What is blocked, and who is taking care of the blocker today?
- Only at the very end: do we have room to pull something new?
Small tickets flow better
A limit of four works badly if one of those four tickets takes three weeks. Large items clog the column and block everything else. So slice work in a way that a ticket can be finished within a few days. Atlassian gives roughly 16 hours per task as a rough guide. The same principle applies to code: if you split pull requests, you get faster reviews and therefore a review column that overflows less often.
Short idle time is fine
Unusual, but important: it is okay if someone briefly cannot pull anything and cannot help anywhere. That time is well spent on tests, documentation or sharing knowledge. It only becomes a problem when someone hoards a big “background task” so they are never without work. Then the limit is mere cosmetics, and its actual message does not get through.
Common mistakes when setting WIP limits
Teams setting WIP limits rarely stumble over the right number. Most problems arise because the limit is written on the board but nobody lives with the consequences. These five patterns are especially widespread:
- Raising it as soon as it pinches: The limit is meant to be uncomfortable. If you raise it at every bottleneck, you only measure what happens anyway.
- Invisible work: Support, operations and requests via chat bypass the board. The limit looks respected, yet people are still overloaded.
- Limits per person: “Nobody more than two tickets” sounds fair but encourages lone wolves. A limit per column or for the whole team invites people to help each other instead.
- Leaving out blocked tickets: If you exclude blocked work from the count, you make room for new work and forget the old.
- Too many columns: Nobody maintains eight columns with eight limits for long. Start with a few and only refine when you have a reason.
My take as a team lead
To me, WIP limits are less a method than a leadership topic. Setting WIP limits is quick, the number is on the board within seconds. It gets hard the moment a manager turns up with a “really urgent little thing”. If I as a team lead do not respect the limit myself, the team has no reason to care about it either. My job is rather to protect the limit and make priority calls explicit: if the new thing is more important, what do we put aside for it?
Just as clear to me is the boundary in the other direction. WIP limits are a team agreement, not a control instrument. Anyone who starts deriving performance comparisons between individuals from them destroys exactly the trust a team needs to say “we are full” out loud. Without psychological safety, people would rather keep that sentence to themselves.
Where I disagree: some guides treat WIP limits like a law of nature that every team needs in every situation. For a team of two, a single limit for the whole board is often enough; column limits would be bureaucracy. And one more thought that catches me out myself: the principle applies to managers too. Whoever drives twelve initiatives at once has the same problem as a board with twelve tickets in progress.
Flow metrics for fine-tuning
To adjust your limits sensibly, you need numbers instead of gut feeling. The Kanban Guide names four flow metrics a team should track at a minimum. You may rename them if other terms work better for your team.
| Metric | What it measures | What you use it for |
|---|---|---|
| WIP | Number of started, not yet finished tasks | Comparing against the agreed limit |
| Throughput | Finished tasks per unit of time, for example per week | How much the team actually completes |
| Work item age | Time since an open task was started | Daily early warning for stuck tickets |
| Cycle time | Time from start to completion of a task | Basis for forecasts and commitments |
In day-to-day work I find work item age the most useful. You only learn a ticket’s cycle time once it is finished, which is too late to intervene. The age of an open ticket, on the other hand, is visible every day. Combined with a service level expectation such as “85 percent of our tickets are done after eight days”, you immediately know which ticket deserves attention today. How to use numbers like these without sliding into control mania is something I described in the article on metrics for AI-generated code. The idea carries over well.
Once your throughput becomes more stable, you can also derive delivery dates from it. I show how that works without an estimation session in my article Monte Carlo forecasting: delivery dates without story points.
FAQ
What is a good WIP limit for a team?
There is no universal number. A proven start is a value slightly below your measured average and, for “In progress”, below the number of team members. After that, you fine-tune based on throughput and work item age.
Do WIP limits work in Scrum?
Yes, Scrum teams can benefit from setting WIP limits too. Scrum defines what happens in a sprint but says little about how work flows within it. A WIP limit on the sprint board means fewer half-finished tickets are left at the end of the sprint. Scrum.org offers a dedicated Kanban Guide for Scrum Teams on this.
Do blocked tickets count towards the WIP limit?
Yes, they should count. A blocked ticket has been started and is not finished; it ties up attention and context. If it does not count, room opens up for new work and resolving the blocker drops out of sight.
Should I set WIP limits per person?
Usually not. Limits per person encourage working alone and can feel like performance monitoring. Limits per column or for the whole board make the bottleneck visible and invite people to help one another.
Your next step
Start small, before setting WIP limits at all: from tomorrow, count every day for two weeks how many tickets sit in each column. Nothing more. Bring the numbers to your next retro and propose a first starting value together that you try out for four weeks. If you want to read more about the structure behind good team decisions, you will find further guides in the blog.
Over to you: how many tickets are “In progress” on your board right now – and how many people are on your team? Let me know in the comments.
Sources
- The Kanban Guide (version 2025.5)
- Atlassian: Working with WIP limits for kanban
- Wikipedia: Little’s law
- Scrum.org: The Kanban Guide for Scrum Teams
This post was created with AI assistance.
👉 Next step: More for team leads: my cheat sheets put the essentials on one printable page.
📬 Stay updated: New articles on serverless, AI and leading tech teams via RSS, browser push or the weekly newsletter (in German).
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en
Top comments (0)