WIP Limits: How to Set Them and What Changes When You Do

A team uses wip limits to cap how many items a column, a person, or the whole group can have in progress at once. You set the number from how much the team finishes, then hold it until items stop aging. In return you get shorter cycle time and fewer half-done tickets.

Say the cap is three and someone wants to start a fourth item. Before they can, something already open has to finish, get unblocked, or go back to the queue.

What the cap covers

Work in progress is anything started and not finished. A bug in review counts. So does a feature waiting on copy, and so does the spike that has been "almost done" for a week. The backlog and Done columns don't count.

The phrase work in progress limits means the most you allow in that started-but-not-finished state. You can put the cap on a column, a person, a class of work, or the whole board. Once you hit it, nobody pulls a new item until one leaves.

Treat the number as a ceiling. A column limited to four with two items in it is fine if those two are moving. Empty slots are slack, and filling one "because we have room" rebuilds the queue you were trying to remove. The cap has nothing to do with velocity or a story-point budget, and a busier board can deliver slower.

Why the amount in progress sets the wait

Little's Law says average work in progress equals throughput times average cycle time. If finishes hold steady and you cut how much is open, cycle time falls. Cycle time is the clock from start to finish on one item, and the number of items allowed to start is the part you can change this week.

Most of that clock is queue time. A ticket in review spends most of its life waiting, and every extra card delays the cards behind it. Three half-done changes usually take longer than finishing one and then the next.

A cumulative flow diagram shows the pile-up. A stage's band grows when more items enter than leave, so if arrivals rise and departures stay flat, the limit is missing or people are ignoring it. Expect a short dip in the first week while people clear what they already opened, and judge the change on the weeks after that.

How to set wip limits

Start from finished work, not headcount.

Use a week of finishes as the first guess

Pick the stage you want to protect, usually build through review. Count how many items left that stage each week over the last four to six weeks. Count items rather than points, unless your items really are the same size.

A sensible starting cap for the whole stage is roughly what the team finishes in a week, often a little less. Six finishes a week suggests a cap of four to six across the active columns. That's a team total, not six per person. The reasoning "two each and we are eight, so sixteen" fills the board with sixteen slow tickets, because review, test, and release are shared.

With no history, start at one item per person in that column, minus one shared slot for review or pairing. Then correct that first guess as data comes in.

Put it on the column that actually swells

Where the wait shows up	A limit that helps	A limit that misses
Review sits for days	A cap on Review, lower than Doing	A cap only on Doing, so Review becomes the dump
One person holds five tickets	A per-person cap of one or two	A team total nobody feels
Test or release is the bottleneck	A cap on the stage that feeds it	A cap on the backlog
Everything is "in progress"	One cap on the whole in-progress area	Several caps you never add up

A column cap protects a stage, and a person cap protects focus. Use both when one engineer is carrying half the board. On a small board that everyone watches, one team cap is enough. Leave the backlog and Done uncapped.

A worked example

A team of five finishes about eight tickets a week. Doing holds seven and Review holds six, and Review is where items get old. They set Doing to four and Review to three: seven in flight, just under a week of finishes. Stand-up stops being about "what did you start?" and turns into "what is stuck in Doing or Review?"

In week one, two people can't start their next tickets, so they review and chase a decision instead. Four items finish, down from a typical eight. In weeks two and three they finish nine and eight, and pull requests get looked at the same day. Median cycle time falls because the wait fell.

They don't raise the cap just because week one felt awkward. Review goes from three to four only if Doing is clearing and then sitting behind a full Review for a reason one extra slot would fix, like the only reviewer being out. If reviews are slow, the fix is faster reviews; a higher cap just hides the problem.

When to lower, hold, or raise

Lower the cap when cycle time is high and the stage is usually full. Either the number is too loose or people are working around it.

Hold it when cycle time is falling or stable and someone can still pull new work most days. A cap you retune every Monday stops being a rule.

Raise it only when that column is the bottleneck, work is ready, and one more slot would remove wait. Raising it because a stakeholder wants more items "in flight" puts the queue back. Throughput goes up when you finish faster or add capacity at the scarce step.

Kanban wip on a software board

On a board, kanban wip is the number on a column: how many cards may sit there. Pulling past it breaks the policy. Atlassian describes the same column cap in its Kanban guide to WIP limits.

A few setups work well for software teams:

• Cap Doing and Review separately, and keep Review smaller. Review is a queue, and a big one just stores work.
• Allow one expedite item, and don't add a second "also urgent" lane. While the expedite item is open, the normal caps still hold.
• A blocked ticket still uses its slot. If blocked work were free, every card would get marked blocked and a new one would start. After a day or two, either send it back or unblock it that day.
• "Waiting on design" and "waiting on QA" are still in progress. Hiding them so Doing looks empty hides the queue too. Count them toward the cap, or give them a tight cap of their own.

A wall, a GitHub project, or Jira can all show the number. What matters is that going past the cap is obvious the same day.

What changes when you hold the line

Without a cap, a free hour starts a new ticket. With one, that hour goes to finishing, reviewing, or unblocking something already open, and ordinary tickets stop waiting behind other ordinary tickets. If you track cycle time and lead time separately, cycle time moves first, because lead time still includes the wait before anyone starts. A cap won't shrink a backlog you refuse to say no to.

Finishes often wobble, then settle near the old rate, sometimes a little higher because less time goes to switching. Read throughput and cycle time together, and remember that throughput counts finishes, not starts.

An uncapped board produces stalled tickets and a few heroic finishes. After a few weeks under a real cap, item ages bunch together. A forecast from that history is still a range, but month-old tickets stop dominating it. Marketing can plan a launch against that range instead of a date someone picked in a kickoff.

"We have twelve things on the go" is not a commitment. "We finish about eight a week, so eight is what this month can absorb" is one. If people skip the number whenever a request sounds senior, you don't have wip limits, you have a label. Make every override visible. And splitting one feature into five pull requests still costs five review slots.

Falrow charts cycle time percentiles, cumulative flow, and a Monte Carlo forecast from the tickets the team already runs, so after you tighten a column you can see which stage is swelling. A spreadsheet with real dates does the same job. Cap the late stage first, then whatever is overfeeding it.

FAQ

What is a good starting number?

Start near the number of items the team finishes in a week across the active stages, often a little lower. Don't multiply people by columns. For one person the working number is usually one, or two if they also review. If items still age at the cap, either the cap is too high or the work is blocked. Use cycle time to correct the first figure.

Should blocked tickets count against WIP limits?

Yes. A blocked ticket still holds attention, a branch, or a review slot. If it didn't count, the board would fill with blocked cards plus a fresh set of started ones. Decide how long a blocked item may keep its slot, then either return it to the queue or clear the block. Don't pull a replacement and leave the blocked card where it is.

Do WIP limits reduce throughput?

For a week or two, finishes can dip while the team closes old work. After that, throughput usually sits near what the bottleneck can finish, sometimes a little higher because less time is lost to switching. A cap won't hire anyone or speed up a slow test suite. What it does is stop extra starts from being counted as extra delivery.

Are these only a Kanban practice?

No. Most software teams first met the idea on Kanban boards, but any team that starts more than it finishes can use the same cap. A sprint backlog of fifteen items, all marked in progress on day two, is the same problem inside Scrum. Finish what you opened, and pull the next sprint item only when a slot frees up.