WIP Limits and Kanban Inside Scrum: What Good Looks Like Versus What Bad Looks Like
Scrum and kanban are often positioned as alternatives, but they are compatible. The Scrum Guide does not prohibit teams from applying kanban practices -- including work-in-progress (WIP) limits and flow visualisation -- within a Scrum framework. Teams that use both are sometimes described as practising "Scrumban," though this is an informal label rather than a formalised methodology.
WIP limits are constraints on the number of work items that can be in a given state (or stage of the Scrum board) at the same time. They work against the natural human tendency to start new work rather than finishing existing work, and they make bottlenecks and queues visible. Here is a direct comparison of good and bad practice in applying WIP limits inside Scrum.
What Bad WIP Limit Implementation Looks Like
Bad: WIP limits are set without understanding the team's actual capacity and the natural flow of work through the Scrum board. A WIP limit that is set too high has no effect -- everything that would have been in progress anyway fits within the limit. A WIP limit set too low stops work unnecessarily. The right WIP limit requires observing the team's historical throughput and identifying where queues form.
Bad: WIP limits are treated as optional. If the WIP limit is 'guideline' rather than a hard constraint, team members will exceed it whenever they feel busy, which means it has no effect on flow. A WIP limit either stops new work from being started when the limit is reached or it doesn't. If it doesn't, it isn't a WIP limit.
Bad: WIP limits apply to individual team members rather than to workflow stages. A personal WIP limit (you can only have two items in progress at once) addresses individual multitasking but does not reveal system-level bottlenecks. Stage-level WIP limits (no more than four items can be in the "in review" column at once) reveal where work is queuing in the system.
Bad: When the WIP limit is hit, the team ignores it and carries on. Hitting a WIP limit should trigger a team response: swarm on the blocked items to clear the queue before starting new work. A WIP limit that nobody responds to is a decoration, not a management tool.
What Good WIP Limit Implementation Looks Like
Good: WIP limits are set based on observation. The team reviews their historical throughput data, identifies the stages where work most often queues, and sets WIP limits for those stages specifically. Limits are adjusted over time as throughput data accumulates.
Good: Hitting a WIP limit triggers a team swarm on the blocked stage. When the "in review" column hits its limit, the team stops starting new development and helps clear reviews before pulling new items. This is the intended behaviour and it improves flow.
Good: WIP limits are discussed and adjusted in the Sprint Retrospective. The team reflects on whether their WIP limits are calibrated correctly, whether they are being respected, and what changes would improve flow in the next Sprint.
XNM supports public-sector organisations in implementing agile delivery practices, including flow management and WIP optimisation. Reach out to XNM's program & project delivery advisory team to discuss kanban, WIP limits, and agile flow for your team.