Kanban oder Scrum? Es ist eine der meistdiskutierten Fragen in der agilen Welt — und gleichzeitig eine der am schlechtesten beantworteten. Denn die ehrliche Antwort lautet: Es kommt darauf an. Beide Frameworks haben ihre Stärken, beide haben blinde Flecken, und in vielen Fällen ist eine Kombination (Scrumban) am sinnvollsten. In diesem Vergleich klären wir die echten Unterschiede, räumen mit Missverständnissen auf und zeigen dir, welche ergänzenden Tools beiden Frameworks helfen.
DEFINITION
Scrum ist ein agiles Framework mit festen Rollen (Product Owner, Scrum Master, Developers), festen Ereignissen (Sprint Planning, Daily, Review, Retrospektive) und festen Artefakten (Product Backlog, Sprint Backlog, Increment). Es arbeitet in zeitlich begrenzten Iterationen, den Sprints, typischerweise 1-4 Wochen lang.
DEFINITION
Kanban ist eine Methode zur Steuerung von Arbeit basierend auf Visualisierung und Flussbegrenzung. Die Kernprinzipien: Visualisiere den Workflow, begrenze die parallele Arbeit (WIP-Limits), steuere den Fluss, mache Prozessregeln explizit und verbessere kontinuierlich. Kanban hat keine vorgeschriebenen Rollen, keine Sprints und keine festen Ereignisse.
Scrum Guide
Der Scrum Guide, zuletzt aktualisiert 2020 von Ken Schwaber und Jeff Sutherland, ist die offizielle Definition von Scrum. Auf nur 13 Seiten beschreibt er das gesamte Framework — absichtlich schlank, damit Teams es an ihren Kontext anpassen können. Die wichtigste Erkenntnis: Scrum ist ein Container, kein Kochrezept. Der Guide sagt dir, WELCHE Elemente du brauchst, aber nicht WIE du sie im Detail umsetzt. Genau hier scheitern viele Teams: Sie folgen dem Scrum Guide mechanisch, ohne die Prinzipien dahinter zu verstehen. Scrum funktioniert, weil der Sprint-Rhythmus regelmäßige Inspektion und Adaption erzwingt — nicht weil das Daily exakt 15 Minuten dauert.
Details ansehenPRAXIS-TIPP
Praxis-Tipp: Scrum passt am besten, wenn dein Team an einem komplexen Produkt arbeitet, regelmäßig liefern muss und die Anforderungen sich ändern. Kanban passt besser, wenn Arbeit unvorhersehbar eintrifft (Support, Ops, Maintenance), das Team an vielen kleinen, unabhängigen Aufgaben arbeitet oder ein bestehendes System verbessert werden soll, ohne alles umzuwerfen.
Sprint Planning Canvas
Das Sprint Planning Canvas strukturiert die wichtigste Scrum-Zeremonie: das Sprint Planning. Es bringt Sprint-Ziel, ausgewählte Backlog-Items, Kapazität und Abhängigkeiten auf eine Seite. In der Praxis sehen wir oft Sprint Plannings, die sich in technische Details verlieren, ohne ein klares Sprint-Ziel zu formulieren. Das Canvas verhindert das, weil es das Ziel prominent in den Mittelpunkt stellt. Es eignet sich besonders für Teams, die gerade mit Scrum starten und noch keine Routine in der Planung haben.
Details ansehenUser Story Mapping
User Story Mapping, entwickelt von Jeff Patton, ist ein unverzichtbares Tool für beide Frameworks. Es visualisiert das Product Backlog entlang der Nutzerreise — horizontal die Schritte, vertikal die Priorität. Der Vorteil gegenüber einem flachen Backlog: Du siehst den Zusammenhang zwischen einzelnen Stories und dem Gesamtprodukt. In Scrum nutzt du die Story Map, um sinnvolle Sprint-Ziele zu identifizieren (horizontale Schnitte durch die Map). In Kanban hilft sie dir, die Reihenfolge der Arbeit nach Nutzerwert statt nach Dringlichkeit zu steuern.
Details ansehenMoSCoW Prioritization
MoSCoW Prioritization teilt Anforderungen in vier Kategorien: Must have, Should have, Could have, Won't have (this time). In Scrum hilft MoSCoW dem Product Owner, das Sprint Backlog zu priorisieren und dem Team klarzumachen, was nicht verhandelbar ist und was wegfallen darf, falls die Zeit knapp wird. In Kanban hilft es, die richtige Reihenfolge auf dem Board zu bestimmen. Der Zusatz 'this time' beim Won't ist entscheidend — es bedeutet nicht 'nie', sondern 'jetzt nicht'. Das reduziert Stakeholder-Konflikte erheblich.
Details ansehenPlanning Poker
Planning Poker ist eine Schätzmethode, die vor allem in Scrum eingesetzt wird. Jedes Teammitglied schätzt den Aufwand einer User Story verdeckt mit Zahlenkarten (typischerweise Fibonacci: 1, 2, 3, 5, 8, 13, 21). Die Karten werden gleichzeitig aufgedeckt, und die größten Abweichungen werden diskutiert. Der Wert liegt nicht in der Zahl, sondern in der Diskussion: Wenn jemand eine 3 und ein anderer eine 13 schätzt, hat mindestens einer etwas übersehen. Planning Poker funktioniert auch in Kanban-Teams, wird dort aber seltener eingesetzt, da Kanban weniger auf vorab-Schätzung setzt.
Details ansehenAgile Fluency Model
Das Agile Fluency Model von Diana Larsen und James Shore hilft dir, die richtige Erwartung an den Reifegrad deines Teams zu setzen — unabhängig davon, ob du Scrum oder Kanban nutzt. Es beschreibt vier Zonen: Focusing (Team liefert im Rhythmus), Delivering (Team liefert technische Exzellenz), Optimizing (Team optimiert Geschäftswert) und Strengthening (Team gestaltet die Organisation mit). Jede Zone erfordert andere Investitionen und bringt andere Ergebnisse. Das Modell verhindert die häufige Enttäuschung, wenn ein Team nach drei Monaten Scrum noch nicht die erhofften Business-Ergebnisse liefert — denn dafür braucht es Zone 3, und die dauert Jahre.
Details ansehenACHTUNG
Das größte Missverständnis: Kanban sei einfacher als Scrum, weil es weniger Regeln hat. In Wirklichkeit erfordert Kanban mehr Disziplin: Ohne Sprint-Grenzen musst du WIP-Limits konsequent einhalten, ohne Retrospektive musst du aktiv nach Verbesserungen suchen, und ohne Product Owner musst du die Priorisierung anders lösen. Kanban hat weniger Struktur — das macht es nicht einfacher, sondern anspruchsvoller.
| Kriterium | Scrum | Kanban |
|---|---|---|
| Rhythmus | Feste Sprints (1-4 Wochen) | Kontinuierlicher Fluss |
| Rollen | Product Owner, Scrum Master, Developers | Keine vorgeschriebenen Rollen |
| Planung | Sprint Planning vor jedem Sprint | Kontinuierlich, nach Bedarf |
| Änderungen | Innerhalb des Sprints geschützt | Jederzeit möglich |
| Metriken | Velocity, Sprint Burndown | Lead Time, Cycle Time, Throughput |
| Steuerung | Sprint-Ziel und Sprint Backlog | WIP-Limits und Durchfluss |
| Verbesserung | Retrospektive nach jedem Sprint | Kontinuierlich (Kaizen) |
| Ideal für | Produktentwicklung, komplexe Projekte | Operations, Support, Maintenance, Continuous Delivery |
In der Realität nutzen viele Teams eine Kombination, oft Scrumban genannt: Den Sprint-Rhythmus und die Retrospektive aus Scrum, kombiniert mit dem Kanban-Board und WIP-Limits. Das funktioniert, wenn du den Schutz fester Iterationen willst, aber die Flexibilität brauchst, Arbeit jederzeit nachzuziehen. Die Entscheidung zwischen Scrum und Kanban ist selten endgültig — die meisten Teams iterieren zwischen den Ansätzen und finden über Zeit ihre eigene Balance. Entscheidender als das Framework ist, dass du die Prinzipien dahinter verstehst: Transparenz, Inspektion und Adaption gelten für beide.
KERNAUSSAGE
Scrum gibt dir Struktur, wenn du sie brauchst. Kanban gibt dir Freiheit, wenn du die Disziplin hast. Wähle nicht nach Trend, sondern nach der Art deiner Arbeit.
FAZIT
Wähle Scrum, wenn dein Team an einem komplexen Produkt arbeitet und von festen Rhythmen, klaren Rollen und regelmäßiger Reflexion profitiert. Wähle Kanban, wenn Arbeit unvorhersehbar eintrifft und du maximale Flexibilität brauchst. Und scheue dich nicht vor Scrumban, wenn keines der beiden Frameworks perfekt passt. Ergänze beide mit User Story Mapping für besseres Backlog-Management, MoSCoW für Priorisierung und dem Agile Fluency Model als Kompass für die Teamentwicklung.