Why limiting how much work is in progress makes a team faster, calmer and more predictable. The idea comes from Kanban and Lean, not from Scrum, but any team can use it. About 10 minutes to read.
A WIP limit is a number written on a column of your board. "In Progress: 3" means that at most three cards may sit in that column. When it is full, nobody starts anything new until a card moves on. That is the whole rule. The interesting part is why such a simple rule works so well.
Kanban, not Scrum: the Scrum Guide never mentions WIP limits. They come from the Kanban method, which grew out of Lean manufacturing at Toyota. Many Scrum teams borrow them because the two fit together well. If boards are new to you, start with the Kanban board section of the Scrum guide.
A kitchen has 3 cooks. If the manager takes 20 orders at once and every cook starts 7 dishes, everything is half-cooked, the food goes cold and nothing reaches a table for ages. If each cook finishes one dish at a time, tables get fed one after another.
It sounds backwards. Here is the same work done in two ways: three tasks, A, B and C, each needing one week of effort.
Nobody benefits from work that has been started. They benefit from work that is finished. A WIP limit moves the team's attention from starting to finishing.
Look at the Review column. Work is piling up past its limit of 2.
What the board is telling us: work is stuck waiting for review. The limit is the board's way of saying "stop starting new work and go review!". The right reaction is for people to swarm on the reviews, not to pull more cards into In Progress. Without a visible board and a limit, nobody would notice until the end of the Sprint.
| Do this, not "start a new card" | Why |
|---|---|
| Review a teammate's work | It is the fastest way to move something to Done. |
| Pair up on a card already in progress | Two heads finish a hard card sooner. |
| Help remove a blocker | A blocked card takes up a slot and delivers nothing. |
| Test, or write the missing notes | This is often where the real bottleneck is. |
| Improve something small: a tool, a checklist, an unreliable test | It makes all future work faster. |
Having nothing new to start is not laziness. A little slack is what lets a team react when something urgent arrives.
In the 1950s Toyota realised that making parts nobody was ready for was waste: it tied up money, hid defects and filled the factory floor. Their answer was "pull": each step makes more only when the next step signals that it is ready, using a card called a kanban. Lean is the set of ideas that grew from that.
Work is handed to people whether or not they have room for it. Queues grow, everyone is busy and little gets finished.
People take the next card only when they have room. The amount of work in the system stays matched to what the team can actually finish. The WIP limit is what makes pull real.
| Principle | In plain words | How a WIP limit helps |
|---|---|---|
| Eliminate waste | Stop doing things that do not help the customer. | Half-finished work is the biggest waste of all: paid for, but worth nothing yet. |
| Build quality in | Prevent defects, do not hunt for them later. | Focus and quick reviews catch mistakes while they are fresh. |
| Create knowledge | Learn as you go, and share what you learn. | Finishing sooner means learning sooner. |
| Decide as late as is responsible | Keep options open until you know enough. | Work that has not started can still be changed for free. |
| Deliver fast | Keep the time from idea to done short. | Fewer items in progress means each one finishes sooner. |
| Respect people | Let the people doing the work shape how it is done. | People pull work at their own capacity, so nobody is overloaded. |
| Optimise the whole | Improve the full flow, not just one step. | A limit stops one fast step from flooding a slower one. |
These seven principles come from Mary and Tom Poppendieck's work on Lean Software Development.
Every piece of work is a card on a shared board.
The subject of this page.
Watch how smoothly cards move, not how busy people are.
Write down what each column means and when a card may move.
Meet regularly, briefly, to look at the board and the results.
Change one small thing, see what happens, keep what works.
There is no perfect number. Pick a sensible starting point, then adjust it using what the board shows you.
| Objection | Answer |
|---|---|
| "People will sit idle." | Rarely. There is nearly always a review, a blocker or a teammate to help. And a person with a little slack is worth more than a person too busy to help anyone. |
| "Urgent work cannot wait." | Add an "expedite" lane for real emergencies, with its own limit of 1. If everything is urgent, nothing is. |
| "We are different. We have to multitask." | Almost every team says so. Try a limit for one month and compare how many cards reach Done. |
| "The limit keeps getting broken." | Then it is doing its job: it is showing you a problem. Fix the cause, not the number. |
| "Our manager wants everyone 100% busy." | A road at 100% capacity is a traffic jam. Flow needs some empty space. |
A Sprint is already a kind of WIP limit: the team takes on only what it believes it can finish in the Sprint. Column limits add a second, finer limit inside the Sprint. They stop the familiar pattern in which every card is started on day 1 and everything is "almost done" on the last day.
| What to watch | What you want to see |
|---|---|
| Cycle time (from start to Done, for one card) | Getting shorter and more consistent |
| Throughput (cards finished per week) | Steady or rising |
| Card age (how long an open card has been open) | No card quietly growing old |
| Carry-over (cards unfinished at the end of the Sprint) | Fewer and fewer |