Scrumban vs Kanban vs Scrum: Boards, Methoden, Planung

Agile Vorgehensweisen versprechen schnelle, effektive und erfolgreiche Prozesse, mehr Eigenverantwortungung und Motivation der Mitarbeiter. Und auch, was besonders wichtig ist – zufriedene Kunden. Doch welche Methode ist die richtige für Ihr Projekt? Scrum, Kanban oder Scrumban? In diesem Artikel überprüfen wir kurz die jeweils verwendete Boards, vergleichen die wichtigsten Unterschiede und Gemeinsamkeiten der Methode, und, vor allem, empfehlen, wer, welche Methode und wozu verwenden sollte.
Scrumban vs Kanban vs Scrum Boards
Scrum Task-Board besteht aus zeitlich definierten Sprints. Ein Scrum-Prozess beginnt in der Regel mit der Produktidee, die im sogenannten Produkt-Backlog festgehalten wird. Produkt-Backlog ist ein Katalog mit Aufgaben, die vom Team abgearbeitet werden sollen. Man definiert die Aufgaben im Produkt-Backlog auch als “Wunschliste”. Täglich findet auf 15 Minuten begrenztes Informations-Meeting, Daily Scrum, statt, damit jeder weiß, womit die anderen zuletzt beschäftigt waren, welche Aufgaben sie als nächstes vor haben und welche Schwierigkeiten oder Probleme es evtl. gibt. Dauer eines Sprints darf 4 Wochen nicht überschreiten, aber normalerweise wird Sprint auf 2-3 Wochen begrenzt.
Die Aufgaben in einem Kanban Board und in einem Scrumban-Board werden nicht auf einen bestimmten Zeitraum begrenzt. Haben Sie von To-Do–Listen noch nicht gehört? Dann versuchen wir dies kurz zu erklären. Als typische gelten drei Spaltenbezeichnungen: Aufgaben (Backlog), Bearbeitung (Doing) und Erledigt (Done), die auch als Prozessschritte gelten. Man kann auch nach Bedarf das Board mit so vielen Unterspalten, wie man will, gestalten. So ist es leicht die Aufgaben zu priorisieren und sequenziell abzuarbeiten.

Wer sollte welche Methode verwenden
Es gibt ein paar Aspekte, die bei der Entscheidung zu berücksichtigen sind.
Scrum lohnt sich bei großen, komplexen Projekten, insbesondere mit langfristiger Laufzeit von mehr als einem Jahr. Scrum wählen oft die Enterprise-Teams, deren Ziel ist, den Prozess effizienter zu gestalten.
Kanban hat die einzigartige Fähigkeit, den konstanten Fluss der ankommenden Aufgaben zu bewältigen. Deswegen wird er oft von Support- und Wartungsteams oder für kontinuierliche Produktherstellung gewählt. Im Gegensatz zu der Methodik von Scrum, konzertriert sich Kanban auf die Organisation von kurzfristigen Projekten.
Schließlich: Scrumban wird oft für schnelllebige Projekte verwendet, weil es die Flexibilität von Kanban und die Grundfunktionen von Scrum verbindet. Deshalb wird Scrumban oft in Startups verwendet, oder, wie Kanban, für die kontinuierliche Produktherstellung.
Scrumban vs Kanban und Scrum: Planung
Planungsroutinen definieren, wie die Arbeit während des Prozesses geplant wird und wann die Planungsrunden stattfinden.
In Scrum werden die Produkt-Backlog-Items in jedem Sprint neu priorisiert. Die Planung ist regelmäßig und erfolgt am Anfang jedes Sprints.
In Kanban, andererseits, werden die präzisen Planungen vermieden. Deswegen können die Teams wählen, wann sie die Elemente aus dem Backlog verschieben (Bedarfsplanung) oder wann der Code oder die Version freigegeben wird (Release/Iterationsplanung). In Scrumban, ähnlich wie in Kanban, wird die Planung durchgeführt, wenn die Aufgaben im Backlog erledigt sind.
Scrumban vs Kanban und Scrum: Schätzung
Schätzung ist ein Prozess, wo die Zeit zum Abschließen jedes Items bestimmt wird.
In Scrum wird die Schätzung in der Regel vor dem Beginn des Sprints durchgeführt. Im Allgemeinen müssen die Aufgaben kürzer als die Zeit für Time-Box Iterationen dauern. Wenn nicht, dann werden sie normalerweise in kleinere Items unterteilt.
In Kanban und Scrumban ist die Schätzung der Laufzeit eines Items optional. Nachdem ein Item abgeschlossen ist, ziehen die Teammitglieder einfach das nächste Item aus dem Backlog und beginnen an ihm zu bearbeiten. Einige Teams wählen dennoch die Schätzung für mehr Erwartungssicherheit. Es gibt auch eine andere Möglichkeit die Erwartungssicherheit zu erreichen: man sollte sicherstellen, dass jedes von diesen Items derselben Größe ist.

Scrumban vs Kanban und Scrum: Neue Items in Iterationen
Agile Methodologien definieren auch, wie die neuen Items zu Iterationen hinzugefügt werden.
In Scrum ist es verboten, neue Items während des Sprints hinzuzufügen. Das neue Item muss auf die reguläre Planungssitzung warten, bis es in den Workflow verschieben wird. Wenn ein Projekt viele eingehende Items (z. B., Support) erhält, wird es allgemein empfohlen, Kanban zu verwenden oder auf diese Anforderung in Scrum zu verzichten.
In Kanban und Scrumban ist es möglich die neuen Items hinzuzufügen, wenn es genug Kapazität in der Queue gibt. Deswegen sind Kanban und Scrumban sehr hilfreich für Funktionen mit kontinuierlichem Fluss der neuen Items.
Scrumban vs Kanban: Performance-Metriken
Die Key-Performance-Metrik ist in Scrum das Burn-Down-Chart. Das Burn-Down-Chart zeigt, wie viel Arbeit für jede Iteration jeden Tag oder jede Stunde des Sprints bleibt. Beispiel des Burndown-Charts wird unten gegeben.

Das Hauptziel des Burndown Diagramms ist zu zeigen, wo sich das Team in jedem Sprint befindet – hinter oder vor dem Zeitplan.
In Kanban wird die Leistung durch die kumulative Flussdiagramme und Schätzung von der Bearbeitungszeit gemessen. Kumulatives Flussdiagramm zeigt die Gesamtanzahl der Items, die im Progress sind, sowie die Zeit, in der sie abgeschlossen werden. Durchschnittliche Bearbeitungszeit zeigt, wie viel Zeit man ungefähr braucht, um ein Item abzuschließen. Ein Beispiel der Zykluszeitschätzung wird unten gegeben. Ähnlich wie bei Kanban, wird bei Scrumban die durchschnittliche Durchlaufzeit als eine wichtige Metrik verwendet.
Es ist sehr wichtig zu beachten, dass Scrum, Kanban und Scrumban nur die Empfehlungen sind, und es gibt eine Vielzahl von Möglichkeiten, wie sie je nach Spezifika des Teams eingesetzt werden könnten.
Überlegen Sie noch, welche agile Methode zu wählen? Die folgende Tabelle wird Ihnen helfen, den schnellen Überblick zu bekommen. Scrumban vs Kanban vs Scrum.
Scrum | Kanban | Scrumban | |
Iterationen | 1-4 Wochen Sprint | Kontinuierliche Arbeit Kürzer als eine Woche oder etwas länger | Kontinuierliche Arbeit mit kurzen Zyklen für die Planung und mit längeren Zyklen für die Freigabe |
Arbeitsablauf | Pull-Prinzip mit der frühen Bindung an die Teammitglieder | Pull-Prinzip mit der späten Bindung an die Teammitglieder | Pull-Prinzip mit der späten Bindung an die Teammitglieder |
Planungsablauf | Sprint-Planung | Release / Iteration Planung, Planung nach Bedarf | Planung nach Bedarf für neue Aufgaben |
Priorisierung | Backlog | Optional | Empfohlen für jede Planung |
Leistungsmetriken | Burn-Down | Kumulatives Flussdiagramm, Durchlaufzeit, Bearbeitungszeit | Durchschnittliche Zykluszeit |
Kontinuierliche Verbesserung | Sprint-Retrospektive | Optional | Kaizen-Event als Option |
Meetings | Sprint Planung, Daily Scrum, Retrospektive | Können vermieden werden | Kurzes Kaizen-Event |
Änderungen in den Iterationen | Verboten | Nach Bedarf | Nach Bedarf |
Board | Definiert vor jedem Sprint | Persistent | Persistent |
Rollen | Product Owner, Scrum Master, Team | Nicht definiert, variierend | Nicht definiert, variierend |
Fazit:
Scrum, Kanban und Scrumban sind nur Tools, die dazu dienen, Ihre und Teamarbeit produktiver zu gestalten, und man muss nicht unbedingt alle Regeln einhalten. Viel Erfolg!