1.Why Kanban and Flow-based Scrum is worth getting right
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.
2.How it works in practice
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.
3.Role reality
Kanban inside Scrum is simple to describe and hard to hold. This is what actually happens when a team tries it.
| Textbook theory | Delivery reality |
|---|---|
| Kanban replaces Scrum for continuous work. | Most teams need both: Scrum for the cadence and shared goal, Kanban for the discipline of managing the work between events. |
| Work in progress limits slow the team down. | They slow starting down and speed finishing up. The team that hits Sprint Review with everything still in progress was never actually fast. |
| The board just needs columns. | The board needs explicit policies: what makes an item ready to pull, what blocks it, who owns each column's exit criteria. |
| A pull system removes the need for planning. | It changes what planning decides. You still plan the Sprint Goal. You stop assigning individual tickets to individual people in advance. |
| Flow metrics are a reporting exercise. | They are a diagnostic tool. A rising cycle time three days into the Sprint is the earliest warning you will get that the Sprint Goal is at risk. |
4.Core delivery pillars
Four practices that make flow visible without needing a new framework.
Name every state an item passes through, including the invisible ones like waiting for review. If a state is not on the board, it is not being managed.
Ready to pull, done for this column, blocked: agree the definitions as a team and pin them to the board. Ambiguous policies are the most common cause of a stalled column.
A limit nobody ever hits is decoration. Set it tight enough that the team feels the constraint and has to swarm rather than start something new.
Daily Scrum inspects the board and the WIP limits, not a status list. Sprint Review shows what actually flowed to Done, not what was planned to.
5.Flow health metrics
Track these on the board itself, discuss them daily, never turn them into a target.
How close the team runs to its own limit. Consistently under it means the limit is too loose.
How long an item has sat blocked. Anything over a day needs an owner outside the team.
Spread of cycle times, not just the average. A wide spread hides a policy problem.
Items open longest right now. The earliest warning that something is stuck, not just slow.
6.Situations you will be asked to handle
The module puts you inside 4 decisions rather than asking you to recognise the right answer on a list. Each one is a situation practitioners meet, with several defensible options and consequences that follow from the one you pick. The scenarios below are the shape of the judgment the subject demands.
- Lesson 30.4: Game - turn convention into policy
- Lesson 30.6: Game - does this respect the pull system
- Lesson 30.9: Game - from chaotic board to working pull system
- Lesson 30.11: Game - decision lab, the fourth item nobody needs
7.Common mistakes and why they fail
Treating Kanban and Scrum as mutually exclusive choices
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.
Copying WIP limits from a template instead of sizing them for the team
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.
Writing vague or missing workflow policies
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.
Abandoning the WIP limit under stakeholder pressure
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.
8.Questions worth asking before you commit time to this
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.
9.What to remember
- How Kanban strengthens Scrum instead of replacing it
- Board policies and work in progress limits that survive contact with pressure
- A situational matrix for keeping flow visible during the Sprint
10.Where this sits in the Scrumling course
Add a pull system, explicit policies and WIP limits to a Scrum team without abandoning Scrum.
About 70 minutes of lessons and decision scenarios.
- Lesson 30.1: Kanban as a strategy, not a replacement framework
- Lesson 30.2: Defining the workflow explicitly
- Lesson 30.3: Making policies explicit
- Lesson 30.5: WIP limits and why they feel wrong at first
- Lesson 30.7: Pull versus push, and the daily behaviour that changes
- Lesson 30.8: Queues, blockers and the difference between blocked and slow
- Lesson 30.10: The Service Level Expectation and running the events on a flow-based team
- Lesson 30.4: Game - turn convention into policy
- Lesson 30.6: Game - does this respect the pull system
- Lesson 30.9: Game - from chaotic board to working pull system
- Lesson 30.11: Game - decision lab, the fourth item nobody needs
Assessment: Kanban and Flow-based Scrum quiz