Two different questions
Kanban and Scrum are often served as two dishes from the same menu. In practice they start from different questions. Kanban asks: where does the work get stuck? Scrum asks: what can we deliver by the end of the cycle? The rest of the comparison follows from there.
Kanban: watching the flow
The Kanban Guide (May 2025 edition) defines Kanban as a strategy for optimizing the flow of value through a process. It rests on three practices: defining and visualizing the workflow, actively managing the items moving through it, and improving the flow. No imposed iteration, no prescribed roles. One requirement is truly firm: control the number of items in progress, from the moment they are started to the moment they are finished.
Why does that limit matter so much? Because it acts directly on how long a task takes to cross the board. Little's law says that in a stable system, the average number of items in progress equals the average throughput multiplied by the average time an item spends in the system (Little, 2011).
An example with numbers made up for the occasion. A support team finishes about 5 tickets a day and always has 20 open: each ticket takes 4 days on average to get out (20 ÷ 5). If the team caps tickets in progress at 8 without its throughput dropping, the average falls to 1.6 days (8 ÷ 5). Nothing was sped up; the team simply stopped starting everything at once.
Scrum: keeping a rhythm
The 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland describes Scrum as a lightweight framework that helps people, teams and organizations generate value through adaptive solutions to complex problems. It is precise on a few points only: Sprints of one month or less, a team of ten people or fewer, three accountabilities (Developers, Product Owner, Scrum Master), five events including the Sprint itself, and three artifacts (Product Backlog, Sprint Backlog, Increment). Each Sprint pursues a single objective, the Sprint Goal. Details are in our article on the Scrum method.
What changes in practice
| Criterion | Kanban | Scrum |
|---|---|---|
| Starting question | Where does work stall? | What do we deliver at the end of the Sprint? |
| What gets bounded | The number of items in progress | The length of the Sprint (one month at most) |
| Required roles | None | Product Owner, Scrum Master, Developers |
| Changing your mind mid-way | Possible at any time, within the WIP limit | The backlog can be reordered; only the Product Owner can cancel a Sprint |
| Common measures | Cycle time, throughput | Sprint Goal met or not (velocity is a widespread practice, but the Guide does not mention it) |
How to choose without getting lost
- Work arrives continuously, in small pieces, with no shared deadline (support, content, recruiting): Kanban fits better, since there is no collective deliverable to pin to a calendar.
- The team is building a product or a campaign and wants a regular checkpoint with stakeholders: Scrum provides that rhythm, as long as the events are actually held.
- Kanban without a WIP limit becomes a more presentable to-do list. Scrum without a retrospective that changes anything becomes a series of meetings.
Many teams blend the two. For an overview of what the literature has recorded about Kanban in software, see the systematic review by Ahmad, Markkula and Oivo (2013).
Sources
- Coleman, J., Vacanti, D., et al. (2025). The Kanban Guide (May 2025). kanbanguides.org
- Schwaber, K., & Sutherland, J. (2020). The 2020 Scrum Guide. scrumguides.org
- Little, J. D. C. (2011). OR Forum: Little's Law as Viewed on Its 50th Anniversary. Operations Research, 59(3), 536-549. doi:10.1287/opre.1110.0940
- Ahmad, M. O., Markkula, J., & Oivo, M. (2013). Kanban in software development: A systematic literature review. 39th EUROMICRO Conference on Software Engineering and Advanced Applications, 9-16. doi:10.1109/SEAA.2013.28