Scrum vs Kanban: Hauptunterschiede und wann man was einsetzt

Beide sind agil. Beide nutzen ein Board. Und doch enden Teams, die Scrum mit Kanban verwechseln, entweder mit der Starrheit von Sprints, wo sie kontinuierlichen Fluss gebraucht hätten, oder mit der Ungebundenheit von Kanban, wo sie strukturierte Planung benötigt hätten. Der entscheidende Unterschied ist der Rhythmus: das eine ist zeitlich begrenzt, das andere fließt wie ein Fluss.

Was ist der Unterschied zwischen Scrum und Kanban?

Scrum ist zeitlich begrenzt: Arbeit läuft in festen Sprints (üblicherweise ein bis vier Wochen), mit definierten Rollen und einem verpflichtenden Planungsrhythmus. Kanban ist kontinuierlicher Fluss: Arbeit bewegt sich durch ein Board ohne harte Rücksetzungen, eingeschränkt nicht durch Zeit, sondern durch Work in Progress (WIP)-Limits pro Spalte.

Beide Frameworks entstammen dem agilen und Lean-Denken. Aber ihre Ziele unterscheiden sich. Scrum wurde für unvorhersehbare, explorationsintensive Produktarbeit entwickelt, bei der Teams strukturierte Feedback-Schleifen brauchen. Kanban, das seine Wurzeln im Toyota Production System (TPS) der 1940er-Jahre hat, wurde für die Flussoptimierung entwickelt, bei der das Ziel ein stabiler Durchsatz und minimale Engpässe sind, nicht Sprint-Velocity.

Key Facts

• Der Scrum Guide wurde 1995 von Jeff Sutherland und Ken Schwaber erstmals kodifiziert und zuletzt 2020 überarbeitet. Die Überarbeitung 2020 vereinfachte das Framework und ersetzte "Development Team" durch "Developers."
• Kanban für Wissensarbeit wurde von David J. Anderson in seinem 2010 erschienenen Buch "Kanban: Successful Evolutionary Change for Your Technology Business" (Blue Hole Press) formal kodifiziert, obwohl seine Fertigungsursprünge auf Taiichi Ohnos Toyota Production System der 1940er-Jahre zurückgehen.
• Laut dem 17. Annual State of Agile Report (2023) nutzen 87 % der Befragten Scrum oder ein Scrum-Hybrid als primäre Methode, während 56 % Kanban und 9 % Scrumban verwenden. Viele Teams gaben an, mehr als einen Ansatz zu nutzen.

Auf einen Blick: die 10 größten Unterschiede

Der schnellste Weg, um zu sehen, wo die beiden Frameworks tatsächlich auseinandergehen:

Rhythmus und Planung

Scrum-Sprints sind nicht verhandelbar. Das Team einigt sich auf ein Ziel, zieht Punkte aus dem Backlog und ändert diesen Scope nicht mitten im Sprint. Das schafft einen Zwang: alle ein bis vier Wochen liefert das Team etwas, überprüft es mit Stakeholdern und passt die Richtung an. Es ist ein Rhythmus, um den herum man planen kann.

Kanban hat keinen Sprint. Arbeit kommt an, wird priorisiert und fließt durch das Board, sobald Kapazität verfügbar wird. Die Planung ist schlank: ein Befüllungsmeeting, um den oberen Teil der Warteschlange aufzufüllen. Es gibt keine Verpflichtung, "was wir diese Woche abschließen werden." Die Verpflichtung erfolgt auf Ebene der einzelnen Einheit, verfolgt durch Durchlaufzeit (wie lange braucht eine Einheit von Beginn bis Fertigstellung?).

In der Praxis kämpfen Scrum-Teams häufig mit "Sprint-Theater", bei dem die Zeremonien stattfinden, das Sprint-Ziel aber fiktiv ist. Kanban-Teams kämpfen oft mit dem Gegenteil: alles ist in Bearbeitung, WIP-Limits werden ignoriert, und das Board wird zum Parkplatz. Beide Probleme sind Disziplinprobleme, keine Framework-Probleme.

Rollen und Zeremonien

Scrum hat drei Rollen und fünf Events:

Rollen: Product Owner (besitzt den Backlog, definiert Prioritäten), Scrum Master (coacht den Prozess, beseitigt Blocker), Developers (bauen das Produkt). Alle drei sind für das Funktionieren von Scrum erforderlich.

Events: Sprint-Planung, Daily Scrum (das 15-minütige Stand-up), Sprint-Review, Sprint-Retrospektive und der Sprint selbst. Diese sind nicht optional, obwohl Teams routinemäßig versuchen, die Retrospektive zu überspringen.

Kanban schreibt überhaupt keine Rollen vor. Kein Kanban Master, kein Product Owner-Äquivalent in der Spezifikation. Teams haben in der Praxis oft einen Flow Manager oder Service Delivery Manager, aber das ist eine organisatorische Entscheidung, keine Framework-Anforderung. Optionale Rhythmen umfassen Befüllungsmeetings (Warteschlange füllen), Lieferplanung, Service-Delivery-Reviews und Retrospektiven. Keine davon ist vorgeschrieben.

Deshalb ist Kanban leichter in ein bestehendes Team einzuführen. Es wird nicht verlangt, dass Personen ihre Stellenbezeichnungen ändern. Der Workflow wird lediglich sichtbar gemacht und WIP-Limits eingeführt.

Kennzahlen: Velocity vs. Durchlaufzeit

Scrum misst Velocity: wie viele Story Points (oder ähnliche Einheiten) schließt das Team pro Sprint ab? Velocity ist für die Sprint-Planung und grobe Kapazitätsprognosen nützlich. Zur Vorhersage, wann eine bestimmte Einheit geliefert wird, eignet sie sich nicht.

Kanban misst Durchlaufzeit (wie lange braucht eine Einheit von "begonnen" bis "fertig"?) und Durchsatz (wie viele Einheiten schließt das Team pro Zeiteinheit ab?). Diese sind prädiktiver für einzelne Liefergegenstände: Wenn die durchschnittliche Durchlaufzeit 3 Tage mit geringer Schwankung beträgt, kann einem Stakeholder mit echtem Vertrauen gesagt werden: "Diese Einheit ist wahrscheinlich bis Donnerstag fertig."

Das kumulative Flussdiagramm ist die Signaturkarte von Kanban: Es zeigt das Arbeitsvolumen in jeder Phase über die Zeit und macht Engpässe als sich verbreiternde Bänder sichtbar. Das Scrum-Burndown-Chart zeigt die verbleibende Arbeit in einem Sprint. Beide sind nützlich; sie messen unterschiedliche Dinge.

Wann Scrum, wann Kanban: ein Entscheidungsbaum

Die ehrliche Antwort: nach dem tatsächlichen Eintreffen der Arbeit entscheiden, nicht nach dem Prestige eines Frameworks.

Scrum einsetzen, wenn:

• Die Arbeit erkennbare Produktziele hat, die von strukturierten Entdeckungszyklen profitieren.
• Das Team sich auf einen Sprint-Scope verpflichten kann, ohne dass alles ein "Notfall" ist.
• Lernschleifen wichtig sind: etwas liefern, daraus lernen und die Richtung korrigieren, bevor mehr gebaut wird.
• Stakeholder von regelmäßigen, vorhersehbaren Review-Checkpoints profitieren.
• Ein Produkt mit einer Roadmap gebaut wird, kein Ticket-Warteschlangen-Abarbeiten stattfindet.

Kanban einsetzen, wenn:

• Arbeit unvorhersehbar eintrifft: Support-Tickets, Betriebsanfragen, Wartungsarbeit.
• Durchsatzoptimierung wichtiger ist als Sprint-Velocity.
• Das Team keinen fixen Scope zusagen kann, weil Unterbrechungen zur Arbeit gehören.
• Ein Einstieg mit wenig Zeremonien in strukturiertes Workflow-Management gewünscht ist.
• Ein bestehender Prozess verbessert wird statt ein neues Produkt entdeckt.

Scrumban einsetzen, wenn:

• Die Starrheit von Scrum überwunden ist, aber noch ein gewisser Planungsrhythmus gewünscht wird.
• Im selben Team eine Mischung aus geplanter Produktarbeit und ungeplanter Support-Arbeit vorliegt.
• Sprints größtenteils aus dem Umbenennen derselben Tickets bestehen und Retros keine Änderungen bringen.

Eine nützliche Heuristik: Wenn der Projektstrukturplan des Teams zwei Wochen im Voraus mit vernünftiger Sicherheit definiert werden kann, passt Scrum. Wenn nicht, passt Kanban besser. Und wenn das Gantt-Diagramm größtenteils Fiktion ist, weil der Scope sich ständig verschiebt, sollte man nachlesen, wozu ein Gantt-Diagramm tatsächlich dient, bevor man sich für eines der beiden entscheidet.

Häufige Mythen und Missverständnisse

Teams wählen oft das falsche Framework, weil sie auf einen Mythos reagieren statt auf ihre tatsächliche Situation:

• "Kanban hat keine Regeln." Es hat weniger Zeremonien, aber die Regeln sind real. WIP-Limits sind keine Empfehlungen. Ihre Verletzung signalisiert ein systemisches Problem, das gelöst werden muss, keine WIP-Limit, das gestrichen werden sollte.
• "Scrum ist reifer oder professioneller." Reife ist irrelevant. Netflix setzt auf Kanban-beeinflusste Flusssteuerung. Software-Produktteams bei Amazon verwenden Sprint-basierte Ansätze. Das richtige Tool hängt von der Arbeit ab, nicht vom Prestige.
• "Man kann sie nicht mischen." Scrumban existiert genau deshalb, weil Teams Wert darin fanden, Elemente beider zu kombinieren. Frameworks sind keine Religion.
• "Kanban-Boards sind Scrum-Boards." Ein Board ist nur ein Visualisierungswerkzeug. Das Scrum-Board setzt sich nach jedem Sprint zurück und zeigt den Sprint-Status. Das Kanban-Board ist dauerhaft, zeigt Workflow-Phasen und erzwingt WIP-Limits. Gleiche Möbel, anderer Raum.
• "Tägliche Stand-ups sind Kanban." Das Daily Scrum ist eine Scrum-Zeremonie. Kanban schreibt kein tägliches Stand-up vor, obwohl viele Kanban-Teams eines einführen. Die Zeremonie nicht mit dem Framework verwechseln.
• "Scrum funktioniert bei Hardware." Das kann es, aber Methode des kritischen Pfads und PERT-Charts passen bei Hardware-Entwicklung oft besser, weil Hardware echte sequenzielle Abhängigkeiten hat, die Sprint-Rücksetzungen nicht ändern.

Scrumban: beide kombinieren

Corey Ladas beschrieb Scrumban 2008 in einem Aufsatz als Weg, Teams von Scrum zu Kanban zu überführen. In der Praxis entwickelte es sich zu einem eigenen Hybrid: Teams behalten einen Sprint-ähnlichen Planungsrhythmus bei (ein "Trigger", der auslöst, wenn der Backlog unter einen Schwellenwert fällt), während sie WIP-Limits und Flow-Metriken von Kanban auf dem Board selbst verwenden.

Es ist besonders nützlich für Teams, die halb Produkt, halb Support sind. Die Produktarbeit profitiert von Sprint-Zielen und Review-Zyklen. Die Support-Arbeit kann nicht auf eine Sprint-Grenze warten. Scrumban erlaubt es, dringende Punkte zu bearbeiten, ohne Sprint-Verpflichtungen zu sprengen.

Das Risiko: Scrumban kann auch eine Ausrede sein, um der Disziplin beider Frameworks auszuweichen. Wenn "Scrumban" gerufen wird, aber WIP-Limits immer 10 sind und Sprint-Ziele immer "was diese Woche reingekommen ist", hat man weder Scrum noch Kanban. Man hat ein beschriftetes Whiteboard.

Häufig gestellte Fragen

Ist Kanban eine Methodik oder ein Tool?

Es ist eine Methodik. "Kanban-Board" ist ein Artefakt der Kanban-Methode, aber Kanban selbst ist eine Reihe von Praktiken zur Steuerung und Verbesserung des Flusses: Arbeit visualisieren, WIP begrenzen, Fluss steuern, Prozessregeln explizit machen, Feedback-Schleifen implementieren und kollaborativ verbessern. Das Board ist das sichtbarste Element, aber WIP-Limits und Flow-Metriken machen es zu einer Methode statt einer Haftnotizen-Gewohnheit.

Kann ein Team mitten im Projekt von Scrum zu Kanban wechseln?

Ja, aber bewusst. Der häufigste Übergang erfolgt während einer Team-Retrospektive, wenn das Team einig ist, dass Sprint-Zyklen keinen Mehrwert mehr liefern. Die praktischen Schritte: keine Sprints mehr planen, WIP-Limits auf dem bestehenden Board explizit machen, Durchlaufzeit statt Velocity messen und eine Flow-Review statt Sprint-Review durchführen. Während des Übergangs nicht Sprint und Kanban gleichzeitig betreiben. Ein Datum setzen und wechseln.

Braucht man in Kanban einen Scrum Master?

Nein. Kanban hat keine vorgeschriebenen Rollen. Manche Organisationen setzen einen "Flow Manager" oder "Service Delivery Manager" ein, um Befüllungsmeetings zu leiten und WIP-Limits zu schützen, aber das ist keine Vorgabe der Kanban-Methode. Teams, die von Scrum zu Kanban wechseln, behalten ihre Scrum Masters oft in einer Coaching-Rolle, was in Ordnung ist. Nur sollte klar sein, dass die Rolle jetzt optional und nicht mehr verpflichtend ist.

Was ist einfacher als Einstieg: Scrum oder Kanban?

Kanban ist für die meisten Teams einfacher als Einstieg, weil es keine Umstrukturierung von Rollen oder eine Verpflichtung auf einen neuen Zeremonienkalender erfordert. Kanban kann eingeführt werden, indem einfach der bestehende Workflow auf einem Board sichtbar gemacht und WIP-Limits vereinbart werden. Scrum erfordert Rollenklarheit (wer ist der Product Owner?) und Zeremonieenverpflichtung (wir führen alle zwei Wochen Sprint-Planung durch), bevor es wie konzipiert funktioniert. Allerdings ist der strukturierte Rhythmus von Scrum oft ein Vorteil für Teams, die einen Zwang zum regelmäßigen Liefern brauchen. Wenn das Team eine Geschichte von "wir veröffentlichen, wenn es fertig ist" auf unbestimmte Zeit hat, kann der Sprint-Druck von Scrum genau das Richtige sein.

---

Die meisten Teams verbringen Zeit damit, darüber zu streiten, welches Framework "besser" ist, wenn sie fragen sollten, welches zu ihrem tatsächlichen Arbeitseingang passt. Scrum gibt alle ein bis vier Wochen eine strukturierte Feedback-Schleife. Kanban gibt Klarheit über den Fluss und Vorhersagbarkeit auf Ebene der einzelnen Einheit. Beide übertreffen das Arbeiten mit einer gemeinsamen Tabelle. Mit demjenigen beginnen, das zum Arbeitsmuster passt, es ehrlich messen und von dort aus iterieren.

Für Teams, die neben ihrer agilen Arbeit strukturierte Projektpläne erstellen, kann eine RACI-Matrix die Entscheidungsverantwortung über Sprint-Teams hinweg klären. Und wenn der Wasserfall-Methodik-Hintergrund zur sequenziellen Planung zieht, ist die Sprint-Struktur von Scrum in der Regel die bessere Brücke als direkt zum kontinuierlichen Fluss von Kanban zu springen.