Scrum vs Kanban
What the two share, and how they differ in cadence, limits, change, roles and metrics, plus when to choose each.
Transcript
Scrum and Kanban both make work visible on a board.
Both aim for steady delivery and constant improvement.
Scrum works in fixed-length sprints, committing to a goal up front.
Kanban is a continuous flow: new work is pulled in when there is capacity.
Scrum limits work by time. Kanban limits it with a work-in-progress limit.
Scrum protects the sprint from change. Kanban welcomes change at any time.
Scrum prescribes roles and events. Kanban prescribes none.
Scrum tracks velocity. Kanban tracks cycle time.
Choose Scrum for product work that benefits from a steady rhythm.
Choose Kanban when work arrives unpredictably, like support or operations.
Many teams blend both, often called Scrumban.
Pick the rhythm that fits the work.
More in this series
1:12Why do we need Scrum?
The problems with plan-everything-first delivery: late feedback, changing requirements and rising cost of change, and how many small bets fix them.
1:17Why Scrum is empirical
Why complex work needs steering by evidence, and how transparency, inspection and adaptation depend on each other.
1:04Why short sprints?
Why timeboxes create fast feedback, smaller risk and protected focus.
1:27Why Scrum roles and events exist
The problem each Scrum accountability and event solves.