Kanban vs. Scrum im direkten Vergleich
Agilität ist weiterhin hoch im Kurs und das hat berechtigte Gründe: Laut einer Studie der BCG sind agile Unternehmen wirtschaftlich erfolgreicher.
Die beliebtesten und am häufigsten verwendeten agilen Arbeitsweisen in Unternehmen sind Scrum und Kanban. Wir zeigen Gemeinsamkeiten und Unterschiede beider Methoden auf.
Außerdem erfährst du, wann welche Arbeitsweise besser geeignet ist und in welchen Fällen du sogar auf ein hybrides Modell (Scrumban) setzen solltest.

Scrumban – die Kombination aus Scrum und Kanban – hat sich bei uns in der Praxis bewährt. Es vereint die Vorteile beider Methoden.
Was ist Scrum?
Scrum ist ein agiles Framework für die Arbeit in Teams. Das Framework wurde von Ken Schwaber und Jeff Sutherland, den Ur-Gründern der agilen Softwareentwicklung, ins Leben gerufen.
Scrum wird dafür eingesetzt, um ein Produkt mit größtmöglichem Nutzen zu entwickeln. Die Regeln von Scrum sind im Scrum Guide beschrieben.
Die Produktentwicklung verläuft in immer wiederkehrenden Zyklen (1-, 2- oder 4-wöchig), den sogenannten Sprints. Der Prozess innerhalb des Sprints ist klar definiert, die Scrum Meetings geben den Rahmen vor.
Nach jedem Zyklus steht ein auslieferbares Produktinkrement bereit, das den Stakeholdern im Sprint Review präsentiert wird.

Auf Basis des Feedbacks optimiert und erweitert das Team im darauffolgenden Sprint das Produkt.
Das schrittweise Vorgehen beruht auf dem empirischen Ansatz “Trial-and-Error”. Das heißt: Das Team lernt, komplexe Probleme zu lösen, in dem es sukzessiv vorgeht, in kleineren Schritten, bis es den optimalen Weg findet.
So reduziert das Team Komplexität und kann gleichzeitig flexibel auf neue Anforderungen eingehen, die sich heutzutage rasch verändern können.
Ein Scrum Team setzt sich aus drei bis neun Personen zusammen. Im Team gibt es mindestens drei Rollen:
- Der Scrum Master ist dafür zuständig, dass das Team den Scrum-Prozess einhält.
- Der Product Owner definiert die Anforderungen und gibt die Richtung vor.
- Die Developer sind für die Umsetzung verantwortlich.
Außerdem setzen wir auch auf die Rolle der UX Designer:innen, die maßgeblich die Qualität und Usability des Produkts beeinflusst. Warum Unternehmen von UX Design profitieren, erfährst du hier.
Was ist Kanban?
Die Kanban-Methode stammt ursprünglich aus dem Lean Manufacturing und wurde von dem Wirtschaftsingenieur, Taiichi Ohno, in der Produktion von Toyota entwickelt. Später im Jahr 2010 hat David J. Anderson die Kanban-Methode auf die agile Softwareentwicklung angewandt.
Kanban ist ein visuelles Management-Tool, das Aufgaben sowie Projekte visualisiert. Das Ziel ist es, parallel ablaufende Arbeiten zu begrenzen und die Effizienz zu steigern. Es geht darum, die Durchlaufgeschwindigkeit zu reduzieren und Bottlenecks im Prozess zu identifizieren.

Das Herzstück der Methode ist das Kanban-Board. Auf einem Board visualisiert das Team die Aufgaben als Karten und ordnet sie den einzelnen Spalten zu. Die Spalten teilen sich auf die einzelnen Prozessschritte auf. Das kann in simpler Form „To Do“ (zu erledigen), „Doing“ (in Bearbeitung) und „Done“ (erledigt) sein.
Die Karten bearbeitet das Team von links nach rechts. Wird ein Prozessschritt erfolgreich abgeschlossen, wandert die Karte in die nächste Spalte.
Aufgaben, die parallel in Bearbeitung sind, (=WIP) werden begrenzt, um ein fokussiertes Arbeiten zu ermöglichen. So sind die Aufgaben schneller erledigt und es entsteht ein kontinuierlicher Workflow.
Kanban vs. Scrum: Das haben beide Methoden gemeinsam
Auch wenn Scrum und Kanban unterschiedliche Frameworks sind, weisen sie einige Gemeinsamkeiten auf. Beide Methoden sind agile Arbeitsweisen, die auf agilen Prinzipien und Werten basieren.
Beide Methoden haben das Ziel, das Arbeiten in Teams zu erleichtern und auf Veränderungen flexibel reagieren zu können. Denn gegenüber klassischen Projekt-Management-Methoden befolgen Kanban und Scrum keinen vorab fest definierten Plan.
Beides steigert Transparenz
Beide Methoden steigern die Transparenz. Alle im Team wissen über den Stand der Entwicklung oder des Projekts Bescheid. Bei Kanban macht das Board die Aufgaben und deren Status sichtbar.
Bei Scrum tauscht das Team Informationen auf täglicher Basis miteinander aus und stellt in jedem Sprint das Produktinkrement allen Stakeholdern vor.
Die Zusammenarbeit verbessert sich
Scrum und Kanban sind so gestaltet, dass sie Optimierungspotentiale aufzeigen. Das gilt für das Produkt, aber auch für die Zusammenarbeit. In der Retrospektive im Scrum geht es beispielsweise darum, die Zusammenarbeit im Team und die Arbeitsabläufe zu optimieren.
Die Kanban-Methode deckt vor allem Bottlenecks auf, wenn der Prozessfluss ins Stocken kommt.
Eine weitere Gemeinsamkeit ist es, dass beide Teams sich selbst managen. Aufgaben delegieren nicht Projektmanager oder eine Führungskraft, sondern die Kolleg:innen suchen sie sich nach dem Pull-Prinzip selbst aus.
Zusammenfassend lassen sich folgende Gemeinsamkeiten erkennen:
- Beides agile Methoden
- Fokus auf Flexibilität
- Struktur durch Prozess
- Förderung der Transparenz
- Aufdecken von Optimierungspotentialen
- Steigerung der Effizienz
- Selbstverwaltende Teams
- Arbeiten nach Pull-Prinzip
Kanban vs. Scrum: Das unterscheidet beide Methoden
Der wesentliche Unterschied zwischen Kanban und Scrum ist, dass Kanban sich primär auf die Visualisierung der Aufgaben und der Optimierung des Prozessflusses bezieht. Es geht um kurze Vorlaufzeiten, Engpässe sowie Schwachstellen im Prozess, der kontinuierlich verläuft und keinem festgelegten Zyklus folgt.
Scrum gibt ein klares Framework mit definierten Zyklen (=Sprints) vor. Teamrollen sowie Regeltermine sind festgelegt und bieten weniger Interpretationsspielraum. Scrum ist vor allem darauf bedacht, ein Produkt auf Basis von Feedback und Erfahrungen zu entwickeln.
Die Prozessoptimierung spielt bei Scrum zwar auch eine wichtige Rolle, ist aber dem eigentlichen Ziel der Produktentwicklung und -optimierung untergeordnet.
In Kanban werden keine Teamrollen verteilt. Es gibt ggf. einen agilen Coach oder Projektmanager, dessen Funktion einem Scrum Master ähnelt. Einen Scrum Master oder Product Owner wie in Scrum gibt es allerdings nicht.
Das gesamte Team ist für das Board sowie den Prozess verantwortlich. Auch sind bei Kanban keine Teamgrößen definiert wie in Scrum. Ein Scrum Team besteht in der Regel aus drei bis neun Personen.
In Scrum gibt es feste Regeltermine und Timeboxen. Damit sind auch die Dauer von Meetings vorgegeben. In Kanban gibt es weder festgelegte Termine noch einen fixen Zeitrahmen, das gilt sowohl für Meetings als auch für Produktreleases oder Auslieferungen.
Das Team liefert aus, wenn Aufgabenpakete abgearbeitet sind bzw. je nach Bedarf. In Scrum steht nach jedem Sprint eine auslieferbare Produktversion bereit.
Kanban bietet mehr Flexibilität
Das zentrale Element in Kanban ist das Kanban-Board, das die Prozessschritte in einzelnen Spalten abbildet. Alle Aufgaben platziert das Team auf dem Board. Die Spalten können sie individuell gestalten. In der Regel gibt es eine Spalte, die als Backlog fungiert und in der Aufgaben gesammelt werden, die noch zu erledigen sind.
In Scrum ist ein solches Board nicht vorgegeben. Dafür gibt es einige Artefakte, die in den meisten Scrum Teams zum Einsatz kommen wie das Product Backlog, das Sprint Backlog, die User Story Map oder auch das Burn-Down-Chart sowie die Working Agreements.
Auch wenn beide Methoden im Gegensatz zum klassischen Projektmanagement viel Flexibilität bieten, unterscheiden sich Scrum und Kanban in ihrer Ausprägung. In Kanban kann das Team Änderungen jederzeit vornehmen, unabhängig vom Stand des Projekts. So können sie auf unvorhersehbare Ereignisse ad hoc reagieren.
In Scrum sollte das Sprint-Ziel während des Sprints nicht verändert werden. Änderungen sind daher nur empfehlenswert, wenn sie notwendig sind und das Sprint-Ziel nicht gefährden. Im nächsten Zyklus kann das Team Änderungen sowie Feedback aus dem Sprint Review wieder flexibler berücksichtigen.
Wann solltest du welche Methode einsetzen?
So viel zu den Unterschieden und Gemeinsamkeiten. Doch welche Methode ist für dich und dein Team nun die richtige Wahl? Kurze Antwort: Das hängt von deinem Projekt oder Vorhaben ab.
Hier sind vier Fragen und Antworten, an denen du dich orientieren kannst:
1. Wie komplex ist das Projekt oder Vorhaben?
Das ist die wahrscheinlich wichtigste Frage, die du dir im Entscheidungsprozess stellen solltest. In unseren Workshops führen wir häufig die Stacey-Matrix auf, die ordnet die Wahl des agilen Frameworks der Komplexität zu:
Einfach: Sind sowohl die Anforderungen an die Software als auch die Umsetzung klar, so kann der Prozess entweder automatisiert oder die Aufgaben nach der klassischen Wasserfall-Methode abgearbeitet werden.
Für die Wasserfall-Methode sollten mindestens Beziehungen, Ursache und Wirkungen der einzelnen Variablen bekannt sein.
Kompliziert: Bei komplizierten Aufgaben sind Anforderungen und Umsetzung vorhersehbar. Ursachen und Wirkungen der Variablen sind vorhanden. Allerdings weniger offensichtlich und meistens gibt es mehr als einen richtigen Lösungsweg. In diesen Fällen empfiehlt sich die Kanban-Methode, welche zum Beispiel in der Wartung oder im Support häufig zum Einsatz kommt.
Komplex: Sind mehr Variablen unsicher, als dass sie bekannt sind, handelt es sich um ein komplexes Vorhaben, für das Scrum als Framework eine gute Wahl ist. Es gibt zwar Orientierungsmuster, aber Ursachen, Wirkungen und Beziehungen sind nicht vorhersehbar.
Es gibt viele unterschiedliche Ansätze, das Problem anzugehen. Der Lösungsweg lässt sich vorab allerdings nicht planen. Die kurzen Feedbackzyklen in Scrum wirken den Unsicherheiten entgegen und ermöglichen ein schrittweises Vorgehen.
Scrum wird daher häufig in der Entwicklung von komplexen Softwareprodukten oder Serviceleistungen sowie in der Forschung eingesetzt, in denen ein empirisches Vorgehen erforderlich ist.
Chaotisch: Sind nahezu alle Variablen unsicher, die Anforderungen und Umsetzungen betreffen, so können Methoden wie Lean-Startup oder Design-Thinking (dazu haben wir in der lise Academy einen passenden Workshop) Struktur in das Chaos bringen. Diese Frameworks kommen häufig in Start-ups, bei Pilotierungen oder Proto-Typing zum Einsatz.

2. Seid ihr von externem Feedback abhängig?
Wenn ihr auf externes Feedback angewiesen seid, wie z.B. bei der Weiterentwicklung eines Produkts, ist Scrum besser geeignet. Denn in Scrum ist das Einholen von Feedback fester Bestandteil des Prozesses.
Im Sprint arbeitet das Team daraufhin ein Produktinkrement fertigzustellen, das den Stakeholdern präsentiert wird. Auf Basis dessen wird das Produkt im nächsten Sprint weiterentwickelt.
Kanban folgt zwar den agilen Prinzipien, worunter auch der Nutzerfokus fällt, Regeln zum Feedback gibt es aber nicht. Kanban funktioniert sogar besser, wenn Aufgaben weitestgehend unabhängig von externen Personen erledigt werden können, da dies den Prozess nicht behindert. Denn in Kanban geht es ja darum, einen kontinuierlichen Prozessfluss zu generieren.
3. Sind einzelne Aufgaben miteinander verknüpft?
Wenn einzelne Aufgaben häufig voneinander abhängig sind und ein schrittweises Vorgehen notwendig ist, ist Scrum die bessere Wahl. Denn in Scrum werden die Tickets innerhalb des Sprints bearbeitet, Abhängigkeiten kann das Team einfacher berücksichtigen.
In Kanban werden die Tickets ggf. unabhängig voneinander bearbeitet. Es gibt zwar eine bestimmte Reihenfolge, was den Prozess oder die Priorisierung betrifft, Abhängigkeiten lassen sich allerdings schwer abbilden. Das WIP (Work in Progress) wird begrenzt, ansonsten werden Aufgaben gleichzeitig angegangen, soweit es die Kapazitäten erlauben.
4. Wie häufig ist dein Team Änderungen ausgesetzt?
Kanban bietet maximale Flexibilität, was Änderungen im Prozess betrifft. In Scrum sollten Änderungen nicht innerhalb des Sprints erfolgen.
Wenn sich Begebenheiten im Projekt auf wöchentlicher oder sogar täglicher Basis verändern, sollte die Kanban-Methode in Betracht gezogen werden. Denn auch wenn Scrum das flexible Agieren ermöglicht, wird die Entwicklung mittel- bis langfristig gedacht.
Scrumban – das Beste aus beiden Methoden
Kanban funktioniert auch gut in Kombination mit anderen agilen Methoden. So lassen sich Scrum und Kanban in einem hybriden Modell (=Scrumban) miteinander vereinen. Das Kanban-Board kann das Team einsetzen, um Aufgaben zu visualisieren.
Auch das WIP ist sinnvoll zu begrenzen. Die Arbeit mit dem Board lässt sich mit den Regelterminen sowie Teamrollen aus Scrum erweitern. Zeitlich begrenzte Sprints wie in Scrum gibt es in hybriden Teams häufig nicht.
Scrumban ist aber kein fixes Framework. Es gibt verschiedene Möglichkeiten, beide Methoden miteinander zu kombinieren. Teams können die Aspekte auswählen, die am besten zu ihnen passen.

Fazit: Wahl hängt vor allem von Komplexität ab
Sowohl Scrum als auch Kanban basieren auf agilen Werten und Prinzipien. Sie decken Optimierungspotenziale in Prozessen auf und vereinfachen die Arbeit in Teams.
Scrum gibt dabei einen festeren Rahmen vor mit einem zyklenartigen Prozess sowie fixen Regelterminen und klar definierten Teamrollen. Der Fokus liegt vor allem auf der Produktentwicklung. Scrum eignet sich besonders gut für komplexe Vorhaben wie die Entwicklung von Software.
Kanban ist ein Management-Tool, bei dem es vor allem um die Visualisierung von Aufgaben und die Optimierung des Prozessflusses geht. Der Prozessverlauf ist kontinuierlich und das Herzstück das Kanban-Board. Kanban ist vor allem für komplizierte Tätigkeiten empfehlenswert wie in der Wartung oder im Support.
Scrumban ist eine Kombination aus Scrum und Kanban. Teams können die besten Aspekte wählen, diese individuell miteinander verbinden und so von beiden Frameworks profitieren!
Du möchtest mehr über Scrum erfahren?
In unserem lise Scrum Training lernst du alles, was du über Scrum wissen musst. Unsere lise Expert:innen zeigen dir, wie du agile Prozesse im Unternehmen etablierst. Aus der Praxis für die Praxis – denn wir selbst arbeiten seit vielen Jahren agil.
So möchten wir auch dich und dein Team dazu befähigen, agile Projekte erfolgreich umzusetzen. Denn Agilität ist die Arbeitsweise der Zukunft und es führt auf lang oder kurz kein Weg dran vorbei! Wir freuen uns auf deine Anfrage!


