Scrum und Kanban im Vergleich: zeitlich begrenzte Sprints oder kontinuierlicher Fluss, Rollen, WIP-Limits, Metriken und wo das iterationsbasierte Board von East Agile Tracker dazwischen steht.
Scrum und Kanban sind die beiden agilen Methoden, die Teams am häufigsten miteinander vergleichen. Beide machen Arbeit sichtbar, und beide zielen darauf, in kleinen Stücken zu liefern. Sie unterscheiden sich darin, wie sie die Arbeit takten: Scrum plant in festen Zeitfenstern, Kanban zieht Arbeit kontinuierlich nach und begrenzt, wie viel gleichzeitig in Arbeit ist.
Diese Seite vergleicht die beiden. Für die gesamte Familie, einschließlich XP und Lean, siehe Was ist agile Entwicklung?.
Scrum in Kürze
Abschnitt betitelt „Scrum in Kürze“Scrum gliedert Arbeit in Sprints — feste Zeitfenster, meist ein bis vier Wochen lang. Jeder Sprint beginnt mit dem Sprint Planning, in dem das Team die Arbeit auswählt, die es fertigzustellen erwartet, und endet mit einem Review des Gebauten und einer Retrospektive darüber, wie das Team gearbeitet hat.
Scrum benennt drei Rollen:
- Product Owner — verantwortet das Product Backlog und dessen Reihenfolge.
- Scrum Master — coacht das Team im Prozess und räumt Hindernisse aus dem Weg.
- Developers — bauen das Inkrement.
Die zentrale Kennzahl ist die Velocity: wie viel Arbeit das Team pro Sprint fertigstellt; sie fließt in die Planung des nächsten Sprints ein. Siehe Was ist Velocity?.
Kanban in Kürze
Abschnitt betitelt „Kanban in Kürze“Kanban setzt beim Arbeitsablauf an, den das Team bereits hat. Arbeitselemente wandern über ein Board aus Spalten, die Stufen darstellen (zum Beispiel To do → In Arbeit → Review → Fertig). Drei Ideen tragen die Methode:
- Den Arbeitsablauf visualisieren — jedes Element und jede Stufe steht auf dem Board.
- Work in Progress (WIP) begrenzen — jede Spalte hat eine Obergrenze; ein neues Element kommt erst hinein, wenn eines hinausgeht.
- Den Fluss steuern — das Team misst, wie lange Elemente brauchen (Cycle Time, Lead Time), und beseitigt Engpässe.
Kanban kennt keine Zeitfenster und schreibt keine Rollen vor. Geplant wird immer dann, wenn die Warteschlange aufgefüllt werden muss.
Im direkten Vergleich
Abschnitt betitelt „Im direkten Vergleich“| Scrum | Kanban | |
|---|---|---|
| Takt | Feste Sprints (1–4 Wochen) | Kontinuierlicher Fluss |
| Zusage | Die für den Sprint geplante Arbeit | Keine Zusage in Paketen; Arbeit wird gezogen, wenn Kapazität frei ist |
| Rollen | Product Owner, Scrum Master, Developers | Keine vorgeschrieben |
| Änderungen im laufenden Zyklus | Innerhalb eines Sprints unerwünscht | Jederzeit möglich |
| Begrenzung der Arbeit | Die Kapazität des Sprints | WIP-Limit pro Spalte |
| Zentrale Metriken | Velocity, Burndown | Cycle Time, Lead Time, Durchsatz |
| Board | Wird jeden Sprint zurückgesetzt | Dauerhaft |
Die Wahl zwischen beiden
Abschnitt betitelt „Die Wahl zwischen beiden“Keine der beiden Methoden ist grundsätzlich besser. Scrum passt zu Teams, die einen regelmäßigen Planungsrhythmus und eine Prognose auf Basis vergangener Sprints wollen, etwa Produktteams, die Features nach Zeitplan ausliefern. Kanban passt zu Arbeit, die unvorhersehbar eintrifft und so bearbeitet werden muss, wie sie kommt, etwa Support, Betrieb oder Wartung.
Viele Teams mischen beide („Scrumban“): Sie behalten einen Planungstakt bei und achten zugleich darauf, wie viel in Arbeit ist.
Wo East Agile Tracker steht
Abschnitt betitelt „Wo East Agile Tracker steht“East Agile Tracker ist iterationsbasiert und steht damit Scrum und eXtreme Programming näher als Kanban. Für einige der oben genannten Konzepte verwendet es eigene Begriffe:
- Sprints heißen Iterationen. Jedes Projekt legt eine Iterationslänge von 1–4 Wochen fest. Iterationen werden automatisch erstellt; es gibt keinen Sprint, der geöffnet oder geschlossen werden muss. Siehe Iterationen.
- Der Backlog ist eine einzige geordnete Liste. Der Product Owner hält ihn in strikter Prioritätsreihenfolge, und der Backlog projiziert die kommenden Iterationen aus der Velocity. Siehe User Stories und Iterationsplanung.
- Die Velocity bestimmt den Umfang des Plans. Mit eingeschaltetem Iterationen automatisch planen füllt sich die aktuelle Iteration bis zu Ihrer Velocity und nicht weiter. Siehe Eine Iteration planen.
- Jede Story trägt ihren eigenen Zustand. Eine Story durchläuft Unstarted → Started → Finished → Delivered → Accepted, angezeigt auf der Karte, statt durch Spalten des Boards zu wandern. Siehe die Zustandsmaschine.
Es gibt keine WIP-Limits und keinen iterationsfreien Flussmodus. Aus Kanban übernommen sind Sichtbarkeit (jede Story und ihr Zustand stehen auf einem Board) und Flussmetriken: Die Seite Metriken zeigt den Velocity-Trend, den Burndown und die zwischen Iterationen übertragenen Stories.
Weiterführende Lektüre
Abschnitt betitelt „Weiterführende Lektüre“- Was ist agile Entwicklung? — das Manifest und die Familie der Methoden.
- Was ist Velocity? — wie die Velocity berechnet und genutzt wird.
- Was sind Story Points? — relatives Schätzen.