A Friday Checklist for Putting WIP Limits to Work in Scrum
Many teams that recovered from the worst of the pandemic disruption found themselves with the opposite problem: too much started, too little finished. Remote and hybrid working made it easy to pick up another item rather than help close one, and half-done work piled up across the sprint. Scrum does not forbid a remedy here — the Scrum Guide is deliberately quiet about how a team manages its flow inside a Sprint, which leaves room to borrow the most useful idea from kanban: limiting work in progress.
A work-in-progress (WIP) limit is simply a cap on how many items may sit in a given board column at once. When the column is full, the rule is to stop starting and start finishing — you swarm on what is already moving before you pull anything new. It is a small constraint with an outsized effect on predictability, and it does not require changing roles, events, or the Sprint itself.
Before you set a limit
Make your board honest: every state a real item passes through (e.g. In Analysis, In Development, In Review, In Test) should be its own column, not hidden inside one big "Doing".
Watch for one week without any limit and count how many items sit in each column on an average day. That average is your starting reference, not a target.
Agree as a team what "done with this column" means, so an item genuinely leaves before the next is pulled.
Decide who is allowed to break a limit and when — the answer should be "almost never, and only by team agreement."
The checklist you can run this week
Pick one bottleneck column. Do not limit every column at once. Choose the one where items visibly queue — often Review or Test — and start there.
Set the first limit slightly below your observed average. If Review usually holds four items, try three. The mild discomfort is the point: it surfaces the handoff problem instead of hiding it.
Make the limit visible. Write it at the top of the column on the physical or digital board so no one can pull past it by accident.
Define the swarm response. When the limit is hit, agree what people do instead of starting new work — pair on the blocked item, review a teammate's pull request, or clear a dependency.
Talk about breaches in the Daily Scrum. If the limit was exceeded yesterday, ask why. The answer is usually a stuck handoff, an unclear acceptance check, or a dependency on someone outside the team.
Tune at the Retrospective, not mid-Sprint. Adjust the number based on what you learned, in small steps. Lowering a limit too far stalls the board; raising it too high makes the cap meaningless.
What good looks like
After a few Sprints you should see fewer items in progress at any moment, shorter time from start to done for each item, and a Sprint Review where most of what was pulled is actually finished rather than "nearly there." The Sprint Goal becomes easier to defend because the team is converging on it instead of spreading itself thin. If a limit is constantly fought, treat that as data: it is pointing at a real constraint — a slow approval, a single overloaded specialist, an external dependency — that is worth fixing at the source rather than working around.
None of this replaces Scrum; it sharpens it. WIP limits give the Developers a concrete, daily mechanism to protect focus and make the flow of value visible, which is exactly what a Sprint is meant to produce.
If your delivery teams are starting more than they finish and you want help turning flow into a habit that sticks, XNM's program & project delivery advisory can help you put it into practice.