WIP Limits: The Most Underrated Tool in Project Management

Open your team's board right now and count the cards in the "In Progress" column. If you have six people and more than ten cards in flight, you have found the reason your projects feel slow, your deadlines slip, and your standups sound like a list of things that are "almost done."

The fix costs nothing, requires no new tooling, and takes effect in about two weeks: put a number at the top of the column and refuse to exceed it. That number is a WIP limit — a cap on work in progress — and it is the most underrated tool in project management. Teams that adopt it consistently report shorter delivery times, calmer workloads, and fewer half-finished things rotting on the board. Teams that resist it usually resist it for reasons that sound sensible and are wrong.

This guide covers what WIP limits are, the math that explains why they work, how to set your first limits, what to do when you hit them, and how to handle the very predictable resistance you will get from your team and your stakeholders.

What a WIP limit actually is

A WIP limit is a maximum number of work items allowed in a given state at the same time. It can apply to:

• A column — "In Progress: 4" means no more than four cards in that column, ever.
• A person — "Nobody works more than two items at once."
• A whole board — "This team never has more than 10 items between Started and Done."
• A work type — "Maximum one unplanned expedite item at a time."

The limit is a constraint you impose on yourselves, not a target. A column limited to 4 is allowed to hold zero, one, or three cards. The limit only bites when someone wants to pull a fifth item in — and the whole point is what happens at that moment. Instead of starting new work, the team has to finish or unblock existing work first. The limit converts "start something new" from the default behavior into the last resort.

Notice what a WIP limit is not. It is not a productivity quota, not a way to measure individuals, and not a punishment. It is a valve that controls how much water flows through the pipe at once, because pipes that are overfilled do not flow faster — they burst or back up.

Little's Law in plain words

There is a real queueing-theory result behind WIP limits called Little's Law, and you do not need any math background to use it. In its work-management form it says:

Average cycle time = average work in progress ÷ average throughput

Translated: how long an item takes to finish equals how many items you have in flight, divided by how many items you finish per unit of time.

Run the illustrative numbers for a six-person team:

Scenario	Items in progress	Throughput (items/week)	Average cycle time
Overloaded	24	6	4 weeks
Moderate	12	6	2 weeks
Limited	6	6	1 week

Same team, same throughput, same amount of total work delivered per month. The only thing that changed is how much was in flight at once — and cycle time, the thing your stakeholders actually feel, dropped from four weeks to one.

This is the core insight, so it is worth sitting with: starting work does not make it arrive sooner. If your team finishes six items a week no matter what, then a stakeholder's request will be delivered when its turn comes, period. Starting it immediately just means it sits "in progress" for a month instead of sitting "in the queue" for a month — except that in-progress work is worse than queued work, because:

1. It occupies someone's attention. Every open item generates status questions, standup mentions, and mental overhead.
2. It goes stale. A half-built feature drifts out of date; a half-written campaign brief gets overtaken by events.
3. It hides the real state of the project. A board with 24 "in progress" items tells you nothing about what will finish next.

And in practice, throughput does not even stay constant as WIP rises — it falls, because of context switching. Studies of task switching consistently suggest that each additional concurrent responsibility carves a meaningful slice off productive time, with the loss compounding as the number of parallel tasks grows. Someone juggling four workstreams is not 25% allocated to each; they are more like 15% allocated to each, with the remainder burned on reloading context. So the overloaded row in the table above is optimistic: real overloaded teams have both high WIP and degraded throughput, which is why cycle times blow out so dramatically.

If you take one sentence from this article into your next planning meeting, take this one: stop starting, start finishing.

Why teams overload themselves anyway

If high WIP is so obviously bad, why does every board drift toward it? Three forces, all of them human and none of them stupid:

The utilization instinct

Managers are trained to see an idle person as waste. If a developer finishes a task and the next one is blocked, the reflex is to hand them something new. But optimizing for "everyone is busy" and optimizing for "work gets finished fast" are different goals that actively conflict. A highway at 100% utilization is a traffic jam. A team at 100% utilization has no slack to swarm on blockers, absorb surprises, or help a teammate — so items queue behind busy people, and cycle time climbs even though everyone is working flat out.

Starting feels like progress

When a stakeholder asks "have you started on my request?", "yes" feels better to say than "it's third in the queue." So teams start things to generate the feeling of responsiveness, trading real speed for perceived speed. The honest answer — "it's third in the queue and our queue moves about five items a week, so expect it around the 14th" — is more useful to the stakeholder and only possible if your WIP is low enough that your cycle times are predictable.

Blocked work leaks

Someone hits a blocker — waiting on legal review, waiting on an API, waiting on a decision. Rather than fight the blocker, they park the card and pull a new one. Do this for a month and your board accumulates a sediment layer of stalled items, each one aging, each one still consuming a slice of attention. WIP limits make this leak visible immediately: when the column is full and half of it is blocked, the team's only move is to attack the blockers.

How to set your first WIP limits

Do not agonize over the perfect number. The limit will be wrong at first and you will tune it. Here is a starting recipe that works for most teams:

Step 1: Count your current WIP honestly

Include everything genuinely in flight: cards on the board, plus the untracked stuff people are carrying — the "quick favor" for sales, the half-finished doc, the review someone promised. Most teams discover their real WIP is 1.5–2x what the board shows. Get it all on the board first; you cannot limit what you cannot see. (If you're using Openbook, the Kanban room's board and backlog views make this step mostly mechanical — drag the invisible work in from the backlog and look at the columns honestly.)

Step 2: Set the initial limit at roughly current WIP minus 20%

If you have 15 items in flight across 6 people, start with a limit of 12. This is deliberately gentle. A dramatic cut (say, straight to 6) is theoretically better and practically doomed — the team will hit the limit constantly in week one, conclude the system is broken, and revolt. A gentle limit lets the team feel the mechanism working before you tighten it.

Step 3: Choose where the limits live

For a first rollout, keep it simple:

Approach	Rule of thumb	Best for
Per-column	1–1.5 × the number of people who work in that column	Teams with distinct stages (Dev, Review, Test)
Per-person	2 items max per person	Teams with fluid, non-staged work (ops, marketing)
Whole-board	~2 × team size to start, tighten toward 1–1.5×	Small teams, first-time adopters

The per-column approach has a bonus: it exposes bottlenecks. If "Code Review" has a limit of 3 and is permanently full while "In Development" starves, your constraint is review capacity, and no amount of hiring developers will help. That is information you did not have before.

Step 4: Tighten every two to four weeks

Once the team stops flinching, reduce the limit by one or two and watch your cycle time. Keep tightening until cycle time stops improving or the team is frequently idle with nothing legitimate to swarm on. Most teams bottom out somewhere between 1 and 1.5 items per person. Below that, you start creating artificial idleness; above 2 per person, you are paying context-switching tax for nothing.

Step 5: Write down the policy, including the exceptions

A WIP limit without an explicit policy dies the first time an executive asks for a favor. Write three sentences and pin them to the board:

In Progress is limited to N items. When the column is full, we finish or unblock existing work before starting anything new. Genuine emergencies use the Expedite lane (limit: 1), and every expedite is reviewed at the next retro to ask why it was an emergency.

That expedite lane matters. It acknowledges that real fires happen while making them countable. If the expedite lane is used weekly, you do not have emergencies — you have a prioritization problem wearing an emergency costume, and now you have the data to prove it.

What happens when you hit the limit

The first time the column is full and someone has nothing to pull, you will discover whether the WIP limit is real. This moment is the entire mechanism, so choreograph it in advance. The order of operations when you're at the limit and "free":

1. Help finish someone else's item. Pair on it, review it, test it, edit it. This is called swarming, and it is the single behavior that separates teams that flow from teams that queue.
2. Attack a blocked item. Chase the dependency, escalate the decision, find a workaround. Blocked cards do not age themselves out; someone has to fight for them.
3. Improve the system. Fix the flaky test, write the runbook, automate the deploy step. This is slack being invested, not wasted.
4. Only then, and only if the limit genuinely allows, pull new work.

A realistic version of the conversation, two weeks into adoption:

Priya: I shipped the export fix. Board's at the limit — Dan, your payments card has been in review for three days, want a second pair of eyes? Dan: Honestly yes, I'm stuck on the retry logic. Priya: Give me 30 minutes to read it, then let's pair after lunch.

Nothing dramatic happened there. Nobody was idle, nobody started item number thirteen, and the oldest card on the board got attention precisely because it was old. Multiply that small redirection by every day for a quarter and you get the cycle-time drop the math promised.

Swarming feels wrong at first

Two people on one task looks inefficient to anyone raised on utilization thinking. But finishing one item today beats finishing two items next week, for every downstream consumer of the work. Swarming also spreads knowledge — the reviewer who paired on the payments retry logic can now maintain it — which lowers your bus factor as a side effect. If your work items are so siloed that nobody can help anybody, that is a finding too, and a more alarming one than anything about WIP.

Handling resistance: the objections you will hear

Expect pushback. Here are the four objections that come up in nearly every rollout, and responses that work.

"But I'm blocked — you want me to just sit there?" No. The policy above gives you three productive things to do before starting new work, and "chase the blocker" is explicitly one of them. What we are removing is the fourth option — quietly abandoning the blocked item — because that is how boards rot.

"Limits will make us look slow. We'll be telling stakeholders no." You will be telling stakeholders when, which is different from no, and more useful than a yes you cannot honor. Try this script with a stakeholder: "We work from a ranked queue with a limit on active items, which is why our estimates hold. Your request is next in line; based on current cycle time, expect it within two weeks of starting, and it should start Monday." Compare that to the old answer — "we've started it" followed by six weeks of silence. Stakeholders do not actually want their items started. They want them finished, predictably.

"My work is different — I have to wait on other people constantly, so I need multiple items." This is the strongest objection and it deserves a real answer: that is what the limit of two per person is for, and why column limits sit above 1× headcount. Some parallelism is legitimate. The limit exists to stop parallelism at four, five, six items — the range where studies of task switching suggest most of your day disappears into context reloading. If waits are so frequent and long that even two slots always fill up, the fix is to attack the waits (they will now be visible as aging blocked cards), not to raise the limit.

"Management measures us on how much we take on." Then management is measuring inputs when they should measure outputs, and you now have the numbers to make the case. Show throughput and cycle time before and after the limit. Delivering the same six items a week with a one-week turnaround instead of four is a better story for management than any amount of visible busyness. If you cannot win that argument with data, no process change was going to survive anyway.

One more piece of advice on resistance: never let the limit become a stick. The moment "you exceeded WIP" turns into an accusation in a standup, people will game the board — splitting cards, hiding work, marking things done early. The limit is a team agreement about flow, and violations are information ("why did we feel pressure to break it on Tuesday?"), not infractions.

The flow metrics that tell you it's working

You do not need a metrics program to run WIP limits, but three numbers will tell you whether they are paying off. Track them weekly; most board tools, including Openbook's Kanban room with its sprint and flow insights, surface them without spreadsheet work.

Cycle time

Elapsed time from when an item starts to when it finishes. This is the headline metric — the one Little's Law predicts will fall as WIP falls. Look at the 85th percentile, not just the average: "85% of items finish within 8 days" is a promise you can make to stakeholders; an average hides the ugly tail.

Throughput

Items finished per week. Expect it to hold steady or rise slightly as WIP drops (you are recovering context-switching losses). If throughput falls significantly after tightening limits, you tightened too far or your items are too big — see below.

Aging WIP

For each in-progress item, how long has it been in progress? This is your early-warning system. A card at twice your typical cycle time is either blocked, too big, or secretly abandoned, and it should be the first topic at standup — "walk the board, oldest first" is a better standup format than three questions per person.

A note on item size: WIP limits assume items are roughly comparable and reasonably small. If one "item" is a three-month epic, a limit of 4 means nothing. Slice work so most items finish inside a week or two; the limit and the slicing reinforce each other. If you're deciding between running this in a sprint cadence or pure flow, that choice matters less than the limit itself — Scrum vs Kanban: How to Choose (or Blend) Them covers the tradeoff, and either can carry WIP limits.

Anti-patterns: how WIP limits fail

Adoption fails in predictable ways. Watch for these:

• Limits set so high they never bind. A limit of 20 for a six-person team is decoration. If you have not hit the limit in two weeks, it is not doing anything — tighten it.
• The invisible second board. Work migrates to DMs, side spreadsheets, and "quick favors" that never touch the board. Total WIP is unchanged; visible WIP looks great. The countermeasure is cultural: if it takes more than 30 minutes, it gets a card, no exceptions, including for managers.
• Splitting cards to dodge the limit. "Implement login" becomes "implement login (part 1)" and "(part 2)" the moment the column fills. Genuine slicing is good; slicing performed at the instant the limit binds is gaming, and a retro topic.
• The permanent expedite lane. When every third item is an "emergency," the expedite lane has become a bypass. Cap it at one item and review every use.
• Blocked items exempted from the count. Teams argue blocked cards "shouldn't count against us." They must count — the pressure of blocked cards occupying limited slots is exactly what forces the team to resolve blockers instead of accumulating them.
• Managerial override. An executive drops a pet project into the full column "just this once." Once tolerated, the limit is dead. The correct response is a trade: "Absolutely — which of these four items should we set down to make room?" That question is not insubordination; it is the WIP limit doing its actual job, which is forcing prioritization to happen out loud.

A 30-day rollout plan

Here is the sequence that works, condensed to a month:

Week 1 — See. Get every piece of in-flight work onto one board, including the untracked favors. Count WIP per person and per column. Measure baseline cycle time from the last month of finished items (even rough dates are fine). Share the numbers with the team without judgment.

Week 2 — Limit. Agree limits at current WIP minus ~20%, write the three-sentence policy with an expedite lane, and pin it to the board. Agree the swarming order of operations (finish others' work → attack blockers → improve the system → then pull).

Week 3 — Hold. The limit will bind for the first time. Hold it. Run standups by walking the board oldest-card-first. Expect grumbling; log every objection for the retro instead of relitigating it live.

Week 4 — Review and tighten. Run a retro on the limit itself: Where did it bind? What did we do instead of starting new work? What leaked around the board? Recompute cycle time and throughput. If the team is stable, tighten by one or two and repeat monthly.

From there, WIP limits stop being an initiative and become how the board works. They pair naturally with the broader Kanban toolkit — pull policies, explicit column definitions, flow metrics — which the complete Kanban guide covers end to end. And because high WIP is usually a symptom of context switching across too many tools and threads, not just too many cards, it is worth reading about the real cost of context switching alongside this.

The pitch to your team is one sentence long: for one month, we will finish things before we start things, and we will let the cycle-time numbers decide whether we keep doing it. In a decade of watching teams try this, the numbers almost always win the argument.

If you want a board that makes this easy — visible columns, a real backlog, sprint and flow insights built in — Openbook's Kanban room is one of 18 room types you can add to a team space in about a minute. Start free at openbook.work and put a number at the top of your In Progress column this week.