WIP Limits: How to Set Them and Why Teams Skip Them

WIP limits cap how much work a team has in progress at once, and they are the cheapest speed-up most engineering teams never try. The reason is mostly social. A limit means saying "no, finish something first" to a person who wants to start. Abloomify's engineering productivity analytics show how many PRs and tickets are open per engineer and how long each waits, which is usually the argument that gets a limit adopted.

A: WIP limits are a cap on items in progress, set for the whole board or for a single column. When the cap is hit, the team finishes work before pulling anything new. Fewer things in flight means each one reaches done sooner.

A: Little's Law says average cycle time equals work in progress divided by throughput. If a team keeps finishing about the same number of items per week and halves what is in flight, the average item takes about half as long to finish.

A: One active item per engineer for the board, and a lower cap on the review column. Run it for two weeks, then adjust by one. Abloomify tracks open PRs and PR cycle time from GitHub, so you can see the effect without counting cards.

A: They fail when they are treated as a rule from management instead of a team agreement, when the limit sits only on the board and ignores open pull requests, and when nobody looks at cycle time afterward to see if it moved.

A WIP limit is a maximum number of work items allowed in progress at the same time. It can apply to the whole board, to one column such as "In Review," or to one person. When the cap is reached, the team stops starting new work and helps finish what is already open. WIP stands for work in progress, and it comes from lean manufacturing and kanban, where it was a physical cap on the parts waiting between stations. In software the idea is the same but the work is invisible, so the limit has to be written on a board and agreed to out loud. A team of six with a board-wide limit of six is saying that every engineer carries at most one item at a time. Many boards run far above that, and nobody decided it. It just accumulated.

Without a limit, the natural state of a board is full. Starting work is easy and finishing is hard, because finishing needs other people: a reviewer, a tester, a product owner who answers a question. So engineers start the next thing while waiting. Each start feels productive. The board fills, and nothing moves faster.

WIP limits shorten cycle time because of Little's Law, a result from queueing theory: average cycle time equals average work in progress divided by average throughput. It is plain arithmetic. If a team finishes 12 items a week and holds 24 in progress, the average item spends two weeks in the system. Cut work in progress to 12 and keep finishing 12 a week, and the average item spends one week. The big assumption is that throughput holds. In practice it often holds or improves, because engineers lose less time to context switching and to re-reading code they touched ten days ago. Those numbers are an example to show the arithmetic, not a benchmark from any team. Asking people to work faster rarely shortens cycle time. Having less in flight does.

There is a second effect that does not show up in the formula. Work that sits half-done carries a quiet cost. The branch drifts from main, the context fades, and the reviewer has forgotten the ticket. We covered the human side of this in reducing context switching on engineering teams.

Put the first limit where work waits the longest, which on most engineering teams is the review step. Many teams set a limit on "In Progress" and then watch a huge pile build up in "In Review," because moving a ticket to review feels like finishing it. A limit on the whole board stops that leak. A limit on the review column makes it visible. The most useful version for engineering teams is also the simplest: review comes before new work. If there is an open PR assigned to you, you review it before you start a new ticket. That single rule is a WIP limit on pull requests, and it needs no tooling to start.

For how review queues grow and how to shorten them, our guide to reducing code review cycle time goes deeper.

Set the first limit at one active item per engineer, add a smaller cap on the review column, and reserve one expedite slot for production fixes. Then run it for two weeks without changing it. A limit needs a fair trial, and most teams quit after three days because the first week feels slower. During the trial, look at PR cycle time and time to first review. After two weeks, adjust by one in either direction. If cycle time has not moved at all, lower the limit by one. If people are visibly idle and waiting on blocked work, raise it by one. The number matters much less than the habit of reviewing it. Write the limit on the board itself so nobody has to remember it, and agree on what happens when it is hit: the team swarms on the oldest item.

Skip story points for this. A WIP limit counts items, not estimates. Mixing the two makes the limit complicated and invites the estimate inflation we describe in story points.

Teams skip WIP limits because starting feels like progress and stopping feels like failure. A manager sees an engineer waiting on a review and says "pick something else up in the meantime." Reasonable, and also how a board reaches 30 open items. The second reason is that the cost of high WIP is invisible. Nobody sees the PR that sat for four days or the branch that went stale. The third reason is that limits are often introduced as a rule from above, so people route around them. I would rather have a team agree on a limit of three and keep it than have a manager impose a limit of one that everyone games.

I also have mixed feelings about how hard to push this. A WIP limit can be a crutch for a team with a deeper problem, such as one overloaded reviewer or a service nobody else understands. If the limit keeps hitting the same bottleneck, that is the thing to fix. The limit's job is to point at it.

Measure PR cycle time, time to first review, the number of PRs older than three days, and sprint completion. If a WIP limit is working, the first three fall and the fourth holds or rises. If cycle time does not move after two weeks, either the limit is too loose or the real bottleneck is somewhere else. Flow metrics give the wider picture, and cycle time versus lead time explains which clock you are watching. All of it comes from repo and ticket activity, so nobody has to log anything.

Abloomify connects to GitHub and Jira through API integrations and reports PR cycle time, time to first review, review health, PR size, and sprint delivery. It is privacy-first by architecture: PII-free signals only, with no code content, no screenshots, and no keyloggers. The values in the dashboard above are illustrative. The workload balance view shows how work is spread across a team, which helps when the limit keeps hitting the same reviewer. For how velocity reads over several sprints, see team velocity, and for the PR side of the problem, right-sizing diffs and WIP.

Start with one limit, on review, for two weeks. Then look at the numbers.

WIP limits are a cap on how many items can be in progress at the same time, either across the whole board or in a single column. When the cap is reached, nobody starts new work until something finishes. The point is to finish more and start less, which usually shortens cycle time.

Start with one active item per engineer for the whole board, then add a smaller cap on the review column. Run it for two weeks and watch PR cycle time and time to first review. If cycle time stays flat, lower the limit by one. If people sit idle, raise it by one.

Usually the opposite. By Little's Law, average cycle time equals work in progress divided by throughput. If throughput holds steady and WIP drops, cycle time drops. Teams can feel slower at first because they stop starting things, but the work that finishes arrives sooner.

Yes. Open pull requests are work in progress that is easy to forget, because the author has moved on to something else. A cap on PRs awaiting review, or a rule that review comes before new work, is one of the most effective WIP limits an engineering team can set.

Watch PR cycle time, time to first review, and the count of PRs older than three days. If those fall while sprint completion holds, the limit is working. Abloomify reads these from GitHub and Jira through API integrations, so nobody has to count cards by hand.