Scrum und Kanban werden oft als zwei austauschbare Varianten eines Aufgabenboards behandelt. Das greift zu kurz. Scrum ist ein Rahmenwerk für die Entwicklung komplexer Produkte. Kanban ist eine Methode, mit der Teams den Fluss ihrer Arbeit sichtbar machen und systematisch verbessern. Beide können agil eingesetzt werden, lösen aber unterschiedliche Probleme.
Die bessere Frage lautet deshalb nicht „Was ist moderner?“, sondern: Brauchen wir einen festen Lernrhythmus für Produktentwicklung oder müssen wir einen kontinuierlichen Arbeitsfluss beherrschbar machen?
Scrum in einem Satz
Ein Scrum Team arbeitet in Sprints auf ein wertvolles Produktziel hin, überprüft regelmäßig das Ergebnis und passt Produkt und Arbeitsweise anhand des Gelernten an.
Scrum definiert drei Verantwortlichkeiten – Product Owner, Scrum Master und Developers –, fünf Ereignisse sowie drei Artefakte mit jeweils einem Commitment. Der Sprint bildet den festen Rhythmus. Innerhalb dieses Rahmens entscheidet das Team selbst, wie es die Arbeit erledigt.
Kanban in einem Satz
Kanban macht den tatsächlichen Arbeitsfluss sichtbar, begrenzt parallele Arbeit und verbessert das System anhand von Messwerten und Feedback.
Die Methode verlangt keinen Sprint und schreibt keine Scrum-Rollen vor. Teams beginnen mit ihrem aktuellen Prozess, visualisieren ihn, definieren Regeln und begrenzen Work in Progress (WIP). Typische Messgrößen sind Durchsatz, Durchlaufzeit, Alter begonnener Arbeit und Auslastung der Prozessschritte.
Die wichtigsten Unterschiede
| Frage | Scrum | Kanban |
|---|---|---|
| Arbeitsrhythmus | feste Sprints von höchstens einem Monat | kontinuierlicher Fluss |
| Verantwortlichkeiten | Product Owner, Scrum Master, Developers | keine zusätzlichen Rollen vorgeschrieben |
| Planung | Sprint-Ziel und Forecast im Sprint Planning | laufende Auswahl nach Kapazität und Regeln |
| Begrenzung | Sprint-Ziel und ausgewählte Arbeit geben Fokus | explizite WIP-Limits je Prozessschritt |
| Änderung laufender Arbeit | Sprint-Ziel darf nicht gefährdet werden | neue Arbeit, sobald Kapazität verfügbar ist |
| Messung | Ergebnis, Zielerreichung und passende Prognosen; Velocity ist optional | Durchlaufzeit, Durchsatz, Work Item Age und WIP |
| Verbesserung | Review und Retrospektive im festen Takt | Feedbackschleifen passend zum System |
Zwei verbreitete Aussagen gehören korrigiert: Der Scrum Guide schreibt weder Story Points noch Burndown-Charts vor. Auch Schätzungen sind kein Selbstzweck. Entscheidend ist, dass das Team eine verantwortbare Prognose abgeben und Fortschritt zum Ziel transparent machen kann.
Was beide Ansätze verbindet
Scrum und Kanban fördern:
- Transparenz über Arbeit und Hindernisse
- Auswahl statt unkontrolliertem Starten
- frühes Feedback auf Ergebnisse
- selbstorganisierte Entscheidungen im Team
- regelmäßige Anpassung des Arbeitsprozesses
Beide scheitern, wenn ein Board lediglich bereits getroffene Einzelaufträge hübsch sortiert. Agilität entsteht nicht durch Spalten, sondern durch kurze Rückkopplung und die Möglichkeit, auf Erkenntnisse zu reagieren.
Wann Scrum besser passt
Scrum ist eine gute Wahl, wenn:
- ein stabiles, interdisziplinäres Team an einem Produkt arbeitet
- Anforderungen und Lösungsweg nicht vollständig vorhersehbar sind
- ein Product Owner Prioritäten verbindlich entscheiden kann
- das Team in regelmäßigen Abständen nutzbare Ergebnisse liefern kann
- Organisation und Stakeholder bereit sind, Feedback tatsächlich zu verarbeiten
Weniger passend ist Scrum für eine Serviceeinheit, die täglich unabhängige Anfragen mit sehr unterschiedlicher Dringlichkeit bearbeitet. Ein künstlicher Sprint schützt dort womöglich nur den Plan vor der Realität.
Wann Kanban besser passt
Kanban passt häufig zu:
- Betrieb, Support und Wartung
- Redaktion und Marketingproduktion
- Teams mit kontinuierlichem Eingang neuer Arbeit
- Prozessen mit Wartezeiten und Übergaben
- Organisationen, die ihren bestehenden Ablauf schrittweise verbessern wollen
Der leichte Einstieg darf nicht mit Anspruchslosigkeit verwechselt werden. Ein Board ohne explizite Regeln, belastbare WIP-Limits und regelmäßige Auswertung ist eine Aufgabenwand, aber noch kein funktionierendes Kanban-System.
Scrum mit Kanban ergänzen
Die Ansätze schließen sich nicht aus. Ein Scrum Team kann Kanban-Praktiken verwenden, um innerhalb der Sprints Engpässe und zu viel parallele Arbeit sichtbar zu machen. Häufig sinnvoll sind:
- WIP-Limits für Entwicklung, Review und Test
- Messung der Durchlaufzeit
- Regeln für blockierte Arbeit
- ein Service-Level-Erwartungswert für typische Aufgaben
Der Sprint liefert weiterhin Ziel und Lernrhythmus; Kanban verbessert den Fluss dorthin. Diese Kombination ist meist nützlicher als eine Grundsatzdebatte zwischen zwei Lagern.
Eine einfache Entscheidungshilfe
- Kommt Arbeit kontinuierlich und unvorhersehbar herein? Dann beginne mit Kanban.
- Entwickelt ein stabiles Team ein komplexes Produkt mit regelmäßigem Feedback? Dann prüfe Scrum.
- Gibt es weder einen verantwortlichen Priorisierer noch ein gemeinsames Team? Dann löst keine Methode das Organisationsproblem.
- Ist bereits Scrum etabliert, aber Arbeit staut sich? Ergänze Flow-Metriken und WIP-Limits.
Fazit
Scrum schafft einen verbindlichen Rhythmus für empirische Produktentwicklung. Kanban verbessert den Fluss eines bestehenden Arbeitssystems. Wähle den Ansatz nach Art der Arbeit – und erwarte von keiner Methode, fehlende Verantwortung oder dauernde Überlastung zu kaschieren.
