Kanban vs. Scrum

Hier stellen wir die wichtigsten Überlegungen vor, die du bei deiner Wahl zwischen Scrum und Kanban anstellen solltest. Außerdem helfen wir den Unentschlossenen auf die Sprünge.

Max Rehkopf Max Rehkopf
Themen durchsuchen

Agile sind die Ideale und Prinzipien, die uns als Richtschnur dienen. Kanban und Scrum sind Frameworks, die Teams helfen, agile Prinzipien zu befolgen und Aufgaben abzuschließen.

Die Unterschiede zwischen Scrum- und Kanban-Verfahren lassen sich leicht ausmachen. Doch das ist nur eine oberflächliche Betrachtung. Die Verfahren unterscheiden sich zwar, doch die Prinzipien dahinter sind größtenteils identisch. Beide Frameworks helfen dir, bessere Produkte (und Services) reibungsloser zu entwickeln. 

Wo sind wir stehen geblieben?

Agile ist ein strukturierter und iterativer Ansatz für das Projektmanagement und die Produktentwicklung. Er trägt der Unberechenbarkeit in der Produktentwicklung Rechnung und bietet sich selbst organisierenden Teams eine Methode, um auf Änderungen zu reagieren, ohne aus dem Konzept zu kommen. Heute stellt Agile kaum noch einen Wettbewerbsvorteil dar. Niemand kann es sich leisten, ein Produkt über Monate oder gar Jahre in einer Blackbox zu entwickeln. Da ist es wichtiger denn je, seine Sache gut zu machen.

Bei Kanban dreht sich alles um das Visualisieren von Aufgaben, das Begrenzen laufender Arbeiten und das Maximieren der Effizienz (oder des unterbrechungsfreien Arbeitens). Kanban-Teams konzentrieren sich darauf, ein Projekt (oder eine User Story) möglichst schnell abzuschließen. Dazu verwenden sie ein Kanban Board und verbessern kontinuierlich ihren Arbeitsfluss. 

Scrum-Teams legen fixe Intervalle fest, sogenannte Sprints, in denen sie funktionsfähige Software ausliefern. Ihr Ziel ist das Erstellen von Lernschleifen, um Kundenfeedback schnell zu sammeln und einzubeziehen. Scrum-Teams bringen ihre Arbeit voran, indem sie bestimmte Rollen einnehmen, spezielle Artefakte erstellen und regelmäßig Zeremonien abhalten. Eine gute Definition von Scrum findest du im Scrum-Leitfaden.

 

Scrum

Kanban

Rhythmus

Scrum

Regelmäßige Sprints mit fester Länge (d. h. 2 Wochen)

Kanban

Kontinuierlicher Fluss

Release-Methoden

Scrum

Am Ende jedes Sprints

Kanban

Continuous Delivery

Rollen

Scrum

Product Owner, Scrum Master, Entwicklerteam

Kanban

Keine erforderlichen Rollen

Zentrale Messwerte

Scrum

Velocity

Kanban

Vorlaufzeit, Durchlaufzeit, WIP

Änderungsphilosophie

Scrum

Teams sollten während des Sprints keine Änderungen vornehmen.

Kanban

Es kann jederzeit zu Änderungen kommen

Teamkollegen arbeiten an einem Scrum Board | Atlassian Agile Coach

Scrum: Ein strukturierter agiler Ansatz

Scrum-Teams legen sich verbindlich darauf fest, am Ende eines Sprint ein nützliches Arbeitsinkrement auszuliefern. Scrum basiert auf Erkenntnissen: Kleine Arbeitsinkremente helfen dabei, von Kunden zu lernen und eine bessere Entscheidung über das weitere Vorgehen zu treffen. So sieht Scrum im Detail aus: 

Scrum-Rhythmus

Mit Scrum macht deine Arbeit schnelle Fortschritte und ist nach Sprints von zwei bis maximal vier Wochen abgeschlossen. Dabei werden feste Start- und Endtermine bestimmt. Durch den engen Zeitrahmen müssen komplexe Aufgaben in kleinere Storys unterteilt werden und Teams können schnell neue Erkenntnisse gewinnen. Eine zentrale Frage dabei ist: Kann dein Team brauchbaren Code so schnell ausliefern?

Ein Sprint umfasst die Sprint-Planung, den Sprint-Review sowie Meetings, die sogenannten Retrospektiven, und wird abgerundet durch tägliche Scrum-Meetings (Standups). Diese Scrum-Zeremonien sind unkompliziert und werden fortlaufend durchgeführt. 

Release-Methoden

Ad-hoc-Releases in Scrum sind heute gängige Praxis, aber es hat sich lange bewährt, Code am Ende eines Sprints zu veröffentlichen. Teams setzen sich für jeden Sprint ein Ziel, das Sprint-Ziel, und entscheiden sich dann im Sprint-Review-Meeting für oder gegen den Release. 

Scrum-Rollen

In Scrum gibt es drei klar definierte Rollen.

  • Der Product Owner, also der Produktinhaber, vertritt die Wünsche des Kunden, verwaltet das Produkt-Backlog und hilft dem Entwicklerteam, die zu erledigenden Aufgaben zu priorisieren.
  • Der Scrum Master unterstützt das Team dabei, sich stets an den Scrum-Prinzipien zu orientieren.
  • Das Entwicklerteam bestimmt, welche Aufgaben zu erledigen sind, stellt Inkremente bereit und trägt gemeinsam die Verantwortung.

Und wer verwaltet das Scrum-Team? Niemand. Scrum-Teams organisieren sich selbst. Es gibt keine Hierarchie unter den Mitgliedern, sie haben lediglich verschiedene Zuständigkeiten. Ein gemeinsames Ziel schweißt das Team zusammen: ein Produkt zu liefern, das dem Kundennutzen entspricht.

Zentrale Messgrößen

Die Velocity – die Zahl der in einem Sprint abgeschlossenen Story Points – ist die wichtigste Messgröße für Scrum-Teams. Sie ist ausschlaggebend für Festlegungen künftiger Sprints, d. h., wie viel Arbeit das Scrum-Team in einem nächsten Sprint übernimmt. Wenn ein Team durchschnittlich 35 Story Points pro Sprint (Velocity = 35) erledigt, wird es keinen Sprint-Backlog über 45 Story Points vereinbaren.

Änderungsphilosophie

Teams sind bestrebt, während eines Sprints keine Änderungen am Umfang vorzunehmen. Manchmal erfahren Scrum-Teams durch Feedback, dass der Nutzen ihrer aktuellen Aufgabe für den Kunden nicht so groß ist wie erwartet. In solchen Fällen sollte der Sprint-Umfang angepasst werden, damit der Kundennutzen oberste Priorität behält. In der Sprint-Retrospektive sollten Scrum-Teams besprechen, wie sie Änderungen künftig einschränken können, um das potenziell auslieferbare Inkrement nicht zu gefährden.

Weitere Scrum-Methoden findest du unter Was ist Scrum?

Teamkollegen arbeiten an einem Kanban Board | Atlassian Agile Coach

Kanban: Kontinuierliche Verbesserung, flexible Prozesse

Mit Kanban kannst du deine Arbeit visualisieren, Work-in-Progress (WIP) begrenzen und deine Aufgaben schnell zum Abschluss bringen.

Kanban eignet sich ideal für Teams, bei denen viele Anfragen mit unterschiedlicher Priorität und Größe eingehen. Während in Scrum-Prozessen der Umfang stark kontrolliert werden muss, kannst du in Kanban einfach dem Workflow folgen. Werfen wir einen Blick auf dieselben fünf Punkte, damit dir die Entscheidung leichter fällt. 

Kanban-Rhythmus

Kanban basiert auf einer Struktur mit kontinuierlichem Workflow, der es Teams erlaubt, immer schnell zu reagieren und sich rasch neuen Prioritäten anzupassen. Aufgabenelemente –die als Karten dargestellt sind – werden in einem Kanban Board organisiert, wo sie eine Workflow-Phase (Spalte) nach der anderen durchlaufen. Gemeinsame Workflow-Phasen sind To Do (Zu erledigen), In Progress (In Bearbeitung), In Review (In Prüfung), Blocked (Gesperrt) und Done (Erledigt). Doch damit sind längst nicht alle Möglichkeiten ausgeschöpft.

Das Beste an Kanban sind die individuellen Spalten, die du der Arbeitsweise deines Teams anpassen kannst. Mein Team liefert Inhalte aus und unsere Spalten reichen (vereinfacht) von Backlog, Priorisiert und Fertige Entwürfe über Wird geschrieben und Wird entworfen bis hin zu Technische Prüfung und Ausgeliefert. In unserem Board sehen wir, dass wir rund einen Inhalt pro Woche ausliefern und erkennen genau, wo unsere Engpässe liegen (der technischen Prüfung sei Dank).

Release-Methoden

In Kanban werden Updates veröffentlicht, sobald sie abgeschlossen sind. Es gibt weder einen festen Zeitplan noch bestimmte Fälligkeitstermine.

Theoretisch wird in Kanban kein fixer Zeitpunkt festgelegt, an dem eine Aufgabe abzuliefern ist. Wird eine Aufgabe früher (oder später) abgeschlossen, kann sie einfach veröffentlicht werden, ohne dass Release-Meilensteine wie etwa Sprint-Reviews abgewartet werden müssen. 

Kanban-Rollen

Zuständig für das Kanban Board ist das gesamte Team. Manche Teams ernennen einen Agile Coach, aber im Gegensatz zu Scrum gibt es keinen "Scrum Master", der alles am Laufen hält. Es liegt in der gemeinsamen Verantwortung des ganzen Teams, an den Aufgaben im Board zusammenzuarbeiten und sie abzuschließen.

Zentrale Messgrößen

Vor- und Durchlaufzeit sind wichtige Messgrößen für Kanban-Teams. Für sie zählt die durchschnittliche Zeit, die ab Bearbeitung einer Aufgabe bis hin zum Abschluss erforderlich ist. Ein Kanban-Team ist erfolgreich, wenn es seine Durchlaufzeiten verbessern kann.

Das kumulative Flussdiagramm ist ein weiteres Analysetool, mit dem Kanban-Teams die Zahl der Aufgabenelemente pro Phase messen können. Dieses Diagramm gibt Aufschluss über die Engpässe, die gelöst werden müssen, um einen besseren Durchsatz zu erzielen.

Engpässe können auch anhand von WIP-Grenzen (Work-in-Progress-Grenzen) bewältigt werden. Durch eine WIP-Grenze wird die Zahl der Karten in einer bestimmten Spalte zu einem konkreten Zeitpunkt eingeschränkt. Bei Erreichen der WIP-Grenze wird die entsprechende Spalte durch Tools wie Jira Software beschränkt und das Team kümmert sich gemeinsam darum, die jeweiligen Elemente voranzubringen.

Änderungsphilosophie

Kanban-Workflows können sich jederzeit ändern. Neue Aufgabenelemente können dem Backlog hinzugefügt und bestehende Karten je nach Priorisierung gesperrt oder gelöscht werden. Wenn sich die Teamkapazitäten ändern, kann die WIP-Grenze außerdem neu eingestellt und Aufgabenelemente können entsprechend angepasst werden. Flexibilität ist in Kanban das A und O.

Weitere Kanban-Methoden findest du unter Was ist Kanban?

Das Agility-Projekt von Atlassian | Atlassian Agile Coach

Scrum-Tools vs. Kanban-Tools

In der Agile-Community dreht sich die Diskussion nicht um Tools. Wir erleben oft, dass das Tool der Wahl das Framework bestimmt und das Framework schließlich die Prinzipien der Teamarbeit. Wir sind jedoch der Ansicht, dass der Weg der Entscheidungsfindung andersherum ablaufen sollte.  

Sobald du auf bestimmte Scrum-Prinzipien ausgerichtet und mit dem Scrum-Framework zufrieden bist, kannst du dich auf die Suche nach einem geeigneten Scrum-Tool machen. Dasselbe gilt für Kanban. Zugegeben, wir sind nicht unvoreingenommen, aber Jira Software, die Nummer eins der Softwareentwicklungstools agiler Teams, bietet euch alles, was ihr braucht.

Mit den dedizierten Projektarten für Scrum und Kanban kannst du die jeweiligen Framework-Prinzipien mit Jira umsetzen. Außerdem helfen dir am Anfang unsere Leitfäden So geht Scrum mit Jira Software und So geht Kanban mit Jira Software.

Kanban vs. Scrum: Keine leichte Entscheidung

Scrum und Kanban sind "agil wie aus dem Bilderbuch". Dass diese Methoden seit Langem bewährt sind, ist schwer zu leugnen. In anderen Worten: "Scrum und Kanban funktionieren für jedes Team".

Doch deine Entscheidung muss nicht einseitig sein. Hunderte von Teams nutzen hybride Modelle, die sowohl von Scrum als auch von Kanban geprägt sind. Und das ist auch in Jira Software möglich. Wir unterstützen Teams dabei mit unseren kürzlich veröffentlichten Projekten der nächsten Generation.

Mit Projekten der nächsten Generation können Teams die agilen Features auswählen, die am besten zu ihnen passen – sei es nun Scrum, Kanban oder etwas von beidem. Du musst dich nicht von Anfang an auf ein Framework festlegen, sondern kannst dein Modell mit Projekten der nächsten Generation nach und nach mit weiteren starken Features ausbauen, nachdem sich gezeigt hat, womit dein Team gut arbeiten kann (und womit nicht). 

So kannst du dich ohne Bedenken für Scrum- oder Kanban-Prozesse der nächsten Generation entscheiden und dir sicher sein, dass sich beide Vorlagen auf die Anforderungen deines Teams abstimmen lassen. 

Ganz unabhängig von deiner Entscheidung solltest du die Methode deiner Wahl eine Zeit lang beibehalten. Bringe einige Aufgaben aus dem Backlog zum Abschluss und frage dann dein Team, was gut gelaufen ist und wo es gehakt hat. Wenn du Scrum und Kanban ausprobierst und diese Frage stellst, bist du bereits auf dem richtigem Weg zu dem agilen Ansatz, der dich glücklich macht. 

Weiter geht's
Kanplan