WIP Limits in Scrum: The Kanban Mistakes That Stall Sprints
Plenty of Scrum Teams have added a Kanban board and work-in-progress (WIP) limits to their workflow, and the official Kanban Guide for Scrum Teams from Scrum.org endorses exactly this. Done well, WIP limits expose bottlenecks and pull the team toward finishing work rather than starting it. Done carelessly, they create friction without improving flow. After a year of distributed work, where a stalled item can sit unnoticed in someone's home-office queue for days, getting this right matters more than ever. These are the mistakes teams most often make.
Where teams go wrong
Setting the limit too high to matter. A WIP limit that exceeds what the team would ever work on at once changes nothing. The point of the limit is to make the team feel the constraint and finish things before pulling more. If it never bites, it is decoration.
Treating WIP limits as a substitute for the Sprint. Adding Kanban does not remove Scrum. The Sprint, Sprint Goal, and all the events remain. The Kanban Guide for Scrum Teams is explicit that these practices complement the Scrum framework — they do not replace the Daily Scrum, the Sprint Review, or the Retrospective.
Ignoring flow metrics once the board is up. A board with limits but no attention to cycle time, work item age, or throughput is just a wall of sticky notes. The value comes from watching how long items take and acting when they age.
Never letting the team adjust the limit. WIP limits are not handed down once and frozen. The team should inspect and adapt them in the Retrospective — too tight and people sit idle, too loose and items pile up half-finished.
Blocking instead of swarming. When the limit is reached, the right move is for the team to swarm on finishing in-progress work, not to start something new in a different column. Teams that quietly route around the limit lose its entire benefit.
Doing it well
Used properly, WIP limits and the Daily Scrum reinforce each other: the conversation shifts from 'what did I do yesterday' to 'what is blocking the items closest to done.' Keep the practice honest with a few habits.
Set the initial limit slightly below current comfort, then tune it in the Retrospective using real cycle-time data.
Make blocked items loudly visible — for distributed teams, a flag in the tool everyone actually checks beats a corner of a physical board.
When the limit is hit, finish before you start: swarm, pair, or review rather than opening new work.
Review work item age in the Daily Scrum so nothing sits forgotten in a remote queue.
If your teams want to combine Scrum and Kanban flow practices in a way that actually sticks, XNM's program & project delivery advisory can help you set it up and coach it through.