Adding flow discipline to Scrum instead of replacing it
Teams frequently frame Kanban and Scrum as a choice between two competing frameworks, when in practice the most effective option for many product teams is Scrum with Kanban's flow practices layered on top, using explicit workflow policies and work-in-progress limits inside the existing Sprint structure rather than discarding Sprints altogether. This module opens by naming what each framework actually optimizes for, Scrum for a fixed timebox with a Sprint Goal to focus and inspect against, Kanban for continuous flow with explicit policies, and shows where the two reinforce rather than contradict each other.
The core of the module is a set of concrete flow additions a Scrum team can adopt without breaking any Scrum rule: explicit workflow policies for each column on the board, matched carefully to the team's actual process rather than copied from a template, and work-in-progress limits set low enough to create real pull pressure and force the team to swarm on finishing items instead of starting new ones. A policy-matching exercise and a WIP-limit sizing check give practice distinguishing a limit that will actually change behaviour from one set so loosely it changes nothing.
A closing scenario addresses a common tension directly: a team mid-Sprint hits its WIP limit and a stakeholder wants a new, seemingly urgent item started anyway. The module treats the WIP limit as a genuine constraint to defend, not a suggestion, and gives language for explaining why starting more work without finishing existing work rarely produces faster overall delivery, using the team's own flow metrics as evidence rather than assertion.
Mistakes teams make with this material
Assuming a team must pick one framework and abandon the other entirely, when explicit policies and WIP limits can be added inside an existing Sprint structure without breaking any Scrum rule.
Applying a generic work-in-progress limit that does not reflect the team's actual capacity or workflow, which either creates no real pull pressure or blocks the board so often that people start ignoring the limit.
Leaving column definitions on the board implicit, so different team members interpret what qualifies to move a card differently, which undermines the transparency a pull system depends on.
Starting a new urgent item despite the board being at its WIP limit, without addressing why the limit exists, which quietly signals to the team that the limit was never a real constraint in the first place.
Questions people ask
Can a team run Kanban and Scrum together, or do they have to choose one?
They can be combined. A Scrum team can adopt explicit workflow policies and work-in-progress limits inside its existing Sprint structure without giving up the Sprint Goal, the events, or any other Scrum rule. This is often the most practical option for teams with a mix of planned and reactive work.
How do you set a WIP limit that actually changes team behaviour?
Size it against the team's real capacity and current average work in progress, then set it low enough to create genuine pull pressure, typically tighter than feels comfortable at first. A limit copied from a template or set loosely enough never to bind changes nothing.
Why do explicit workflow policies matter for a pull system?
Because a pull system depends on everyone agreeing on what qualifies to move a card between columns. Without a written, shared policy, different team members interpret the board differently, which breaks the transparency the whole system relies on.
What should a team do when a stakeholder wants to start new work despite the board being at its WIP limit?
Defend the limit and explain the trade-off using the team's own flow data: starting more work without finishing existing work usually slows overall completion rather than speeding it up. If the request is genuinely more urgent than everything in progress, something already started should be explicitly deprioritized in its place.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
What is the relationship between Kanban and Scrum according to the Kanban Guide for Scrum Teams?
- Kanban replaces the Scrum events once a team adopts it
- Kanban is a strategy for optimising flow that sits alongside the Scrum Guide, not a competing framework
- Kanban is only for teams that have abandoned Sprints
- Kanban removes the need for a Product Owner
The Kanban Guide for Scrum Teams is designed to be applied within Scrum, adding flow practices without changing accountabilities or events.