MethodenVergleich
Kanban vs. Scrum: Welche Methode passt zu deinem Team?
Inhalt dieses Artikels
Kanban passt zu Teams, deren Arbeit ungleichmäßig hereinkommt und Stück für Stück fertig wird, etwa im Support, im IT-Betrieb oder in einer Redaktion. Scrum passt zu Teams, die ein Produkt weiterentwickeln und für jeden Abschnitt von höchstens einem Monat ein gemeinsames Ziel brauchen. Bei Kanban vs. Scrum entscheidet also nicht, welche Methode besser ist, sondern wie die Arbeit bei deinem Team ankommt.
Als Entweder-oder sehen die Herausgeber beider Ansätze die Frage nicht. Der Kanban Guide der Kanban University schreibt, es gehe nie um Kanban gegen eine andere Methode, sondern immer darum, Kanban zu einer bestehenden Arbeitsweise hinzuzufügen. Scrum.org hat dafür einen eigenen Kanban Guide for Scrum Teams herausgegeben.
Kanban vs. Scrum: die Unterschiede im Überblick
Scrum begrenzt die Zeit, Kanban die Menge. Scrum teilt die Arbeit in Sprints fester Länge von höchstens einem Monat (Scrum Guide 2020). Kanban teilt sie nicht in Abschnitte, sondern legt fest, wie viele Aufgaben gleichzeitig in Arbeit sein dürfen. Aus diesem einen Unterschied folgen fast alle anderen.
| Kriterium | Kanban | Scrum |
|---|---|---|
| Rhythmus | fortlaufender Fluss, keine Iterationen | Sprints fester Länge, höchstens ein Monat |
| Begrenzt wird | Menge begonnener Arbeit (WIP-Limit) | Zeit (Sprint) und Umfang über das Sprint-Ziel |
| Rollen | keine vorgeschrieben, bestehende bleiben | Product Owner, Scrum Master, Developers |
| Feste Termine | keine vorgeschrieben, Frequenz wählt das Team | Sprint Planning, Daily Scrum, Sprint Review, Sprint-Retrospektive |
| Neue Arbeit | beginnt, sobald unter dem Limit Platz frei wird | kommt im nächsten Sprint Planning dazu, vorher nur ohne Gefahr für das Sprint-Ziel |
| Gemessen wird | Work in Progress, Durchsatz, Alter laufender Aufgaben, Durchlaufzeit | Fortschritt zum Sprint-Ziel und zum Produktziel |
| Einführung | beim bestehenden Prozess anfangen, schrittweise ändern | alle Bestandteile zusammen, nur Teile davon sind laut Guide kein Scrum |
Die größte Folge im Alltag betrifft neue Arbeit. Im Scrum-Team wartet eine neue Anfrage in der Regel bis zum nächsten Sprint Planning, denn während des Sprints gilt laut Scrum Guide: keine Änderung, die das Sprint-Ziel gefährdet. Im Kanban-Team rückt sie nach oben in die Warteschlange und beginnt, sobald unter dem WIP-Limit Platz frei wird.
Der zweite große Unterschied ist der Aufwand der Einführung. Kanban beginnt nach dem Grundsatz „Start with what you do now“ aus dem Kanban Guide der Kanban University: Rollen, Titel und Meetings bleiben zunächst, wie sie sind. Der Scrum Guide dagegen hält fest, dass ein Team, das nur Teile von Scrum umsetzt, kein Scrum betreibt. Was zu Scrum gehört, erklärt der Artikel Scrum: Sprints, Events und Artefakte, die Gegenseite der Überblick über die Kanban-Methode.
Scrum-Board vs. Kanban-Board: was sie unterscheidet
Ein Scrum-Board zeigt den Sprint Backlog, also nur die Arbeit des laufenden Sprints, und wird zu Beginn jedes Sprints neu bestückt. Ein Kanban-Board zeigt den ganzen Workflow und läuft ohne Neustart weiter. Der Scrum Guide schreibt gar kein Board vor: Er verlangt nur, dass der Sprint Backlog ein gut sichtbares, aktuelles Bild der Arbeit im Sprint ist.
Den deutlichsten Unterschied siehst du an den Spaltenköpfen. Ein Kanban-Board trägt an jeder Arbeitsspalte ein WIP-Limit, etwa „In Arbeit: 4“. Ein Scrum-Board braucht keine Limits, weil der Sprint die Menge begrenzt: Was im Sprint Planning nicht ausgewählt wurde, kommt nicht aufs Board.
Scrum-Teams, die trotzdem Limits setzen wollen, finden im Kanban Guide for Scrum Teams ein Kanban-Board innerhalb des Sprints, mit beschriebenem Workflow und WIP-Limits. Wie du Spalten und Limits für ein Board festlegst, zeigt die Anleitung zum Kanban-Board.
Wann Kanban besser passt
Kanban passt, wenn die Arbeit nicht planbar hereinkommt, wenn die Aufgaben klein und voneinander unabhängig sind oder wenn ein Team seine Organisation nicht umbauen kann. Für jede der drei Lagen gibt es einen konkreten Grund, der gegen einen Sprint spricht.
Arbeit, die unvorhersehbar hereinkommt
Support, IT-Betrieb und interne Serviceteams können neue Anfragen nicht zwei Wochen bis zum nächsten Sprint Planning liegen lassen. Faustregel: Ist mehr als etwa ein Drittel der Arbeit einer Woche ungeplant, hält ein Sprint-Ziel selten bis zum Ende des Sprints. Kanban nimmt neue Arbeit auf, sobald Platz frei wird, und gibt Notfällen als Faustregel eine eigene Bahn mit einem Limit von einer Karte.
Viele kleine, voneinander unabhängige Aufgaben
In einer Redaktion, einer Personalabteilung oder im Marketing ist jede Aufgabe für sich fertig und für sich nützlich. Ein gemeinsames Ergebnis, das am Ende eines Sprints geprüft werden müsste, gibt es nicht. Kanban misst hier, was zählt: die Durchlaufzeit jeder einzelnen Aufgabe, eine der vier Flow-Kennzahlen aus The Kanban Guide.
Wenn Rollen und Abläufe bleiben müssen
Kann die Organisation keine Product-Owner-Verantwortung mit echter Entscheidungsbefugnis schaffen, fehlt Scrum die Grundlage. Kanban braucht keine neue Stelle und keinen neuen Terminkalender, sondern ein Board, ein WIP-Limit und ein kurzes Treffen am Board. Faustregel: Wer Scrum nicht vollständig einführen kann, fährt mit Kanban besser als mit halbem Scrum, denn halbes Scrum ist laut Scrum Guide kein Scrum.
Wann Scrum besser passt
Scrum passt, wenn ein Team gemeinsam an einem Produkt arbeitet, dessen Anforderungen sich erst beim Bauen klären, und wenn Stakeholder in festem Rhythmus mitentscheiden sollen. Drei Lagen sprechen klar für Sprints.
Produktentwicklung mit offenen Anforderungen
Ein Team baut eine App, ein Kundenportal oder ein neues Kursangebot, und niemand kann vorab alle Anforderungen festlegen. Scrum verlangt laut Scrum Guide 2020 in jedem Sprint mindestens ein nutzbares Inkrement. So zeigt sich nach spätestens einem Monat, ob das Team in die richtige Richtung arbeitet, bevor es zu viel investiert hat.
Ein Team, das ein gemeinsames Ziel braucht
Arbeiten Fachleute aus Entwicklung, Gestaltung und Fachabteilung an einem Ergebnis, gibt das Sprint-Ziel allen denselben Maßstab für die nächsten Wochen. Kanban hat keinen solchen Fixpunkt: Es misst den Fluss einzelner Aufgaben, nicht den Fortschritt zu einem gemeinsamen Ziel. Laut Scrum Guide ist ein Scrum Team funktionsübergreifend: Es hat alle Fähigkeiten, die es braucht, um in jedem Sprint Wert zu schaffen. Wer im Team wofür einsteht, erklärt der Überblick über die Scrum-Rollen.
Stakeholder, die regelmäßig mitentscheiden sollen
Sollen Auftraggeber, Fachabteilung oder Kundschaft in festem Rhythmus sehen, was entstanden ist, und mitbestimmen, was als Nächstes kommt, hat Scrum den Termin dafür schon eingebaut: das Sprint Review. Bei Kanban richtest du einen solchen Termin selbst ein. Faustregel: Wollen deine Stakeholder spätestens alle vier Wochen mitreden, spricht das für Scrum.
Kanban und Scrum kombinieren
Kanban und Scrum lassen sich verbinden, und beide Seiten sehen das vor. Der Scrum Guide 2020 nennt das Rahmenwerk bewusst unvollständig und beschreibt Scrum als Behälter für weitere Techniken, Methoden und Praktiken. Der Kanban Guide for Scrum Teams von Scrum.org, Daniel Vacanti und Yuval Yeret zeigt seit Januar 2021, wie das konkret aussieht.
Ein Scrum-Team mit Kanban behält Sprint, Events und Artefakte und ergänzt vier Praktiken: den Workflow sichtbar machen, Work in Progress begrenzen, laufende Arbeit aktiv steuern und die eigene Beschreibung des Workflows regelmäßig anpassen. Zusätzliche Events braucht es laut Guide nicht. Das Daily Scrum findet am Kanban-Board statt und schaut darauf, wo der Fluss stockt.
Scrum mit Kanban heißt: Der Sprint bleibt, begrenzt wird zusätzlich die Menge paralleler Arbeit.
Weiter geht Scrumban. Corey Ladas hat die Mischform 2008 in seinem Aufsatz „Scrumban“ als Weg für Scrum-Teams beschrieben, nach und nach von festen Planungsterminen zu einer Planung bei Bedarf überzugehen; was dabei vom Sprint übrig bleibt, erklärt der Abschnitt zu Scrumban im Kanban-Artikel. Bevor du Scrumban einführst, prüfe, ob dein Team das Sprint-Ziel noch braucht. Wenn ja, ergänze Kanban-Praktiken im Sprint; wenn nein, ist Kanban ehrlicher als ein Sprint, der nur noch auf dem Papier steht.
Woran die Wahl zwischen Kanban und Scrum scheitert
Kanban wählen, um Meetings zu sparen. Kanban schreibt keine Termine vor, kommt aber ohne Abstimmung nicht aus: Jemand muss neue Arbeit auswählen, jemand muss auf die Kennzahlen schauen. Der Kanban Guide der Kanban University nennt diese regelmäßigen Treffen Kadenzen und rät, sie nach und nach aufzubauen.
Scrum für ein Team, das ständig unterbrochen wird. Ein Team, dessen Sprint-Ziel jede Woche von Störungen gekippt wird, plant für den Papierkorb. Laut Scrum Guide darf keine Änderung das Sprint-Ziel gefährden; wo das dauernd passiert, passt der Rahmen nicht zur Arbeit.
Ein Board ohne Limit für Kanban halten. Spalten machen Arbeit sichtbar, begrenzen sie aber nicht. Erst das WIP-Limit macht aus dem Board ein Pull-System, also eines, in dem sich das Team neue Arbeit erst holt, wenn es Kapazität hat. Der Kanban Guide for Scrum Teams verlangt das Limit ausdrücklich.
Die Methode wechseln statt die Ursache klären. Liegt das Problem in unklaren Prioritäten oder zu vielen Auftraggebern, löst es weder Kanban noch Scrum. Beide machen den Konflikt nur sichtbar. Entscheiden muss weiterhin jemand mit Befugnis, in Scrum der Product Owner, der laut Guide für die Reihenfolge im Product Backlog einsteht.
Fragen und Antworten
Was ist besser, Kanban oder Scrum?
Keines von beiden ist allgemein besser. Kanban passt zu Arbeit, die unvorhersehbar hereinkommt und Stück für Stück fertig wird, etwa im Support oder in einer Redaktion. Scrum passt zu Produktentwicklung, bei der ein Team ein gemeinsames Ziel verfolgt und spätestens nach einem Monat ein nutzbares Ergebnis zeigt. Faustregel: Ist mehr als etwa ein Drittel der Arbeit einer Woche ungeplant, spricht das für Kanban.
Kann man Kanban und Scrum kombinieren?
Ja. Der Kanban Guide for Scrum Teams von Scrum.org beschreibt, wie ein Scrum-Team ein Kanban-Board, WIP-Limits und Flow-Kennzahlen nutzt. Sprint, Events und Artefakte bleiben dabei erhalten, zusätzliche Events braucht es laut Guide nicht. Weiter geht Scrumban: Dort geht ein Team nach und nach von festen Planungsterminen zu einer Planung bei Bedarf über.
Ist Kanban eine agile Methode?
Kanban zählt in der Praxis zu den agilen Methoden, die Idee stammt aber aus der Lean-Produktion von Toyota. Die Autoren des Kanban Guide for Scrum Teams nennen Kanban eine Lean-Agile-Strategie. Die Kanban University beschreibt Kanban ausdrücklich nicht als Methodik, sondern als Managementansatz, den ein Team zu seiner bestehenden Arbeitsweise hinzufügt.
Wann macht Scrum keinen Sinn?
Scrum passt schlecht, wenn die Arbeit so unvorhersehbar hereinkommt, dass kein Sprint-Ziel bis zum Ende des Sprints hält, etwa im Support oder IT-Betrieb. Auch wenn die Aufgaben voneinander unabhängig sind und kein gemeinsames Ergebnis ergeben, fehlt dem Sprint-Ziel der Gegenstand. Und wer nur Teile von Scrum übernimmt, etwa Sprints ohne Retrospektive, betreibt laut Scrum Guide kein Scrum.
Gibt es bei Kanban Sprints?
Nein. Kanban arbeitet ohne Iterationen: Aufgaben fließen fortlaufend durch den Workflow, und neue Arbeit beginnt, sobald unter dem WIP-Limit Platz frei wird. Regelmäßige Termine gibt es trotzdem, etwa ein kurzes tägliches Treffen am Board und eine Runde, in der das Team die nächsten Aufgaben auswählt. Wie oft und wie lange, legt das Team laut Kanban Guide selbst fest.
Braucht ein Kanban-Team einen Scrum Master oder Product Owner?
Nein. Kanban schreibt keine Rollen vor und beginnt mit den Rollen, die es im Team schon gibt. Zwei Aufgaben muss trotzdem jemand übernehmen: entscheiden, welche Arbeit als Nächstes ins Board kommt, und darauf achten, dass das Team seine WIP-Limits einhält. Wer das tut, regelt das Team selbst, zum Beispiel die Teamleitung oder eine fachlich verantwortliche Person.
Kann ein Team von Scrum zu Kanban wechseln?
Ja, und der Schritt ist kleiner, als er klingt. Ein Scrum-Team kann zuerst innerhalb seiner Sprints WIP-Limits einführen und die Flow-Kennzahlen messen, wie es der Kanban Guide for Scrum Teams beschreibt. Zeigt sich nach einigen Sprints, dass das Sprint-Ziel kaum noch hält, lässt das Team die Sprints auslaufen und behält die Retrospektive als festen Termin.
Quellen
- Scrum Guide 2020 (abgerufen am 22. Oktober 2026)
- Kanban Guide (Kanban University) (abgerufen am 22. Oktober 2026)
- The Kanban Guide (Vacanti, Coleman), Fassung vom Mai 2025 (abgerufen am 22. Oktober 2026)
- The Kanban Guide for Scrum Teams (Scrum.org, Vacanti, Yeret), Januar 2021 (abgerufen am 22. Oktober 2026)
- Scrumban (Corey Ladas, Agile Alliance) (abgerufen am 22. Oktober 2026)