← Agile and Scrum: Flexible Project Management
Lesson
Lesson 6.3 — Scrum vs Kanban, and a capstone case analysis
Choose Scrum or Kanban (or a blend) for a situation, then analyze a real team's problem and propose an Agile improvement in writing.
When to use Scrum, when to use Kanban, and how to combine them
When to use Scrum, when to use Kanban, and how to combine them
Scrum fits best when a team is building a complex product that benefits from a regular cadence of planning, review, and retrospective. The Sprint timebox creates a forcing function: every one to four weeks the team integrates everything, demonstrates a working Increment, and adjusts. The Sprint Goal gives the team a shared focus for that iteration. Scrum is well suited to product development where requirements evolve and where stakeholder feedback every Sprint is valuable.
Kanban fits best when work arrives continuously and unpredictably, items vary widely in size and urgency, and releases should happen as soon as items are ready rather than waiting for a Sprint boundary. IT operations, customer support, maintenance queues, and service desks are classic Kanban contexts. There is no fixed iteration — items are pulled and delivered on demand.
The two approaches are not mutually exclusive. Some teams run Scrum for their product development work while tracking flow metrics (cycle time, throughput, WIP) on a Kanban board — an informal combination sometimes called Scrumban. The Scrum Guide does not forbid the use of flow metrics inside Sprints.
A common set of Agile anti-patterns to watch for: using the Daily Scrum as a status report to a manager (it is a planning event for Developers, not a reporting ceremony); treating velocity as a performance KPI or comparing it across teams (velocity is a planning tool, not a measure of productivity); ignoring WIP, which causes cycle times to balloon; and treating the Scrum Master as a project manager or task dispatcher (the Scrum Master is a leader who serves, not a boss).
Lesson notes
When to use Scrum, when to use Kanban, and how to combine them
Scrum fits best when a team is building a complex product that benefits from a regular cadence of planning, review, and retrospective. The Sprint timebox creates a forcing function: every one to four weeks the team integrates everything, demonstrates a working Increment, and adjusts. The Sprint Goal gives the team a shared focus for that iteration. Scrum is well suited to product development where requirements evolve and where stakeholder feedback every Sprint is valuable.
Kanban fits best when work arrives continuously and unpredictably, items vary widely in size and urgency, and releases should happen as soon as items are ready rather than waiting for a Sprint boundary. IT operations, customer support, maintenance queues, and service desks are classic Kanban contexts. There is no fixed iteration — items are pulled and delivered on demand.
The two approaches are not mutually exclusive. Some teams run Scrum for their product development work while tracking flow metrics (cycle time, throughput, WIP) on a Kanban board — an informal combination sometimes called Scrumban. The Scrum Guide does not forbid the use of flow metrics inside Sprints.
A common set of Agile anti-patterns to watch for: using the Daily Scrum as a status report to a manager (it is a planning event for Developers, not a reporting ceremony); treating velocity as a performance KPI or comparing it across teams (velocity is a planning tool, not a measure of productivity); ignoring WIP, which causes cycle times to balloon; and treating the Scrum Master as a project manager or task dispatcher (the Scrum Master is a leader who serves, not a boss).