Scrumban: Scrum und Kanban kombinieren

Scrumban entsteht, sobald man aufhört, sich zwischen Scrum und Kanban entscheiden zu müssen. Teams, die strukturierte Planung brauchen, sich aber keine starren Sprints leisten können, greifen als Erstes zu Scrumban.

Was ist Scrumban?

Scrumban ist ein hybrides agiles Framework, das die kontinuierliche Flow-Mechanik von Kanban über die Planungsdisziplin von Scrum legt. Arbeit bewegt sich über ein pull-basiertes Board mit Work-in-Progress-Limits (WIP-Limits), doch Planungs-Events finden bedarfsgerecht statt statt nach einem festen Sprint-Takt.

Corey Ladas prägte den Begriff 2008 in einem Essay und vertiefte ihn später in seinem Buch Scrumban: Essays on Kanban Systems for Lean Software Development. Sein zentrales Argument: Scrum ist ein gutes Gerüst für Teams, die neu im agilen Arbeiten sind, doch mit wachsender Reife sollten Teams die Zeremonien abbauen, die keinen Mehrwert bringen, und die behalten, die es tun. Das Flow-Modell von Kanban füllt die Lücken. Das Ergebnis ist ein Framework, das flexibel genug für Wartungsarbeiten, Support-Warteschlangen und Marketing-Operationen ist, von denen sich keines sauber in zweiwöchige Sprints pressen lässt.

Wichtigste Fakten

• Der 17. State of Agile Report (2023) ergab, dass 9 % der Befragten einen Scrum/Kanban-Hybrid als primären Liefermodus einsetzten, ein Anstieg gegenüber 6 % zwei Jahre zuvor.
• Teams, die WIP-Limits zusammen mit einem Pull-System einführen, erzielen laut den in Donald Reinertsens Principles of Product Development Flow (2009) zitierten Flow-Verbesserungsdaten typischerweise eine Verkürzung der Durchlaufzeit um 20-40 %.
• Scrumban behält Planungs-Events bei, löst sie aber anhand der Warteschlangengröße aus, nicht nach Kalender, sodass der Planungsaufwand proportional zum tatsächlichen Arbeitsvolumen bleibt.

Scrum vs. Kanban vs. Scrumban

Die drei Frameworks teilen sich ein Board und einen Backlog, unterscheiden sich aber schnell in Takt, Rollen und der Art, wie Arbeit ins System gelangt.

Wenn Ihr Team bereits Scrum praktiziert, aber ständig die Sprint-Regeln biegt, um dringende Anfragen zu bewältigen, sind Sie schon auf halbem Weg zu Scrumban. Und wenn Sie Kanban einsetzen, aber merken, dass Sie nie innehalten, um zu reflektieren oder zu planen, gibt Ihnen das „strukturiert bei Bedarf"-Modell von Scrumban einen Grund zur Pause.

Wie Scrumban funktioniert

Die Mechanik von Scrumban beruht auf vier ineinandergreifenden Ideen.

Pull-System. Arbeit wird Ingenieuren nicht zugewiesen. Sie wird gezogen. Wenn jemand eine Aufgabe abschließt, zieht die Person das nächste Element aus einer Ready-Warteschlange in die eigene Spalte. Das verhindert, dass sich Arbeit in einer einzigen Spur staut, und macht Engpässe sofort sichtbar.

WIP-Limits. Jede Board-Spalte trägt eine Höchstanzahl. Die Spalte „In Arbeit" darf beispielsweise nicht mehr als drei Karten gleichzeitig enthalten. Ist die Spalte voll, konzentriert sich das Team darauf, etwas fertigzustellen, bevor etwas Neues begonnen wird. WIP-Limits sind der wirkungsvollste Hebel überhaupt, um die Durchlaufzeit in jedem von Kanban abgeleiteten System zu senken.

Ready-Warteschlange. Zwischen dem Backlog und den aktiven Arbeitsspalten liegt eine Ready-Warteschlange, ein kleiner Puffer aus aufbereiteten, priorisierten Elementen, die tatsächlich abrufbereit sind. Die Ready-Warteschlange entkoppelt Planung von Ausführung. Planung kann in einem fokussierten Schub stattfinden, danach zieht das Team beliebig aus der Warteschlange, ohne dass ein Planer im Raum sein muss.

Bedarfsgerechter Planungsauslöser. Statt alle zwei Wochen zu planen, egal was ist, löst Scrumban ein Planungs-Event aus, wenn die Ready-Warteschlange unter einen festgelegten Schwellenwert fällt, etwa zwei Elemente pro Entwickler. Das bedeutet, der Planungsaufwand skaliert mit dem tatsächlichen Bedarf. Ruhige Wochen bekommen eine schnelle Auffüllung; arbeitsreiche Wochen brauchen vielleicht gar keine Planung.

Ein Cumulative-Flow-Diagramm ist das naheliegende Tracking-Werkzeug für Scrumban, da es Warteschlangengrößen, WIP und Durchsatz in einer einzigen Ansicht visualisiert. Beginnt sich ein Band zu verbreitern, sammelt sich Arbeit schneller an, als sie fertiggestellt wird.

Vorteile von Scrumban

Flow ohne Chaos. Das Modell des kontinuierlichen Flows von Kanban hält die Arbeit in Bewegung. Scrumban fügt gerade genug Struktur hinzu, damit der Backlog nicht zum Friedhof unangetasteter Tickets wird.

Planung nach eigenen Bedingungen. Teams, die mit Sprint-Planung-Zeremonien kämpfen, die einen ganzen Tag für zwei Stunden echter Entscheidungen beanspruchen, werden den Unterschied sofort bemerken. Planung findet statt, wenn die Warteschlange aufgefüllt werden muss, nicht weil der Kalender es verlangt.

Geringerer Overhead für eingespielte Teams. Sobald ein Team weiß, was es tut, beginnen die Scrum-Zeremonien, die während der Einarbeitung sinnvoll waren, überflüssig zu wirken. Scrumban erlaubt Teams, abzulegen, was ihnen nicht dient, und zu behalten, was hilft.

Bewältigt gemischte Arbeitstypen. Die meisten realen Teams haben es sowohl mit geplanter Arbeit (neue Features, Projekte) als auch mit ungeplanter Arbeit (Bugs, Anfragen, Vorfälle) zu tun. Scrum tut sich mit ungeplanter Arbeit schwer, weil sie den Sprint stört. Scrumban nimmt sie auf, weil das Board außerhalb des normalen Grooming-Zyklus immer Platz hat, um neue Elemente in die Ready-Warteschlange zu ziehen.

Sichtbarkeit. Das Board ist jederzeit aktuell. Jeder kann sehen, was in Arbeit ist, was blockiert ist und wie nah die Ready-Warteschlange daran ist, Planung auszulösen. Niemand muss auf ein Sprint-Review warten, um den Zustand des Systems zu erfahren.

Wo Scrumban an Grenzen stößt

Scrumban ist keine universelle Lösung. Es bringt eigene Fehlermuster mit sich.

Keine Rollen bedeutet keine Verantwortlichkeit. Die definierten Rollen bei Scrum existieren, weil jemand den Backlog verantworten, jemand moderieren und jemand das Team vor Scope Creep schützen muss. Scrumban lässt diese Rollen standardmäßig weg. Teams, die diese Struktur überspringen, enden oft mit einem ungepflegten Backlog, Planungsmeetings, auf die sich niemand vorbereitet, und einem Board, das niemand aktualisiert.

WIP-Limits erfordern Disziplin. Sobald ein Manager das Team zum ersten Mal bittet, „nur noch eine Sache" hinzuzufügen, wird das WIP-Limit still und heimlich angehoben. Sobald Limits zu Vorschlägen werden, bricht die Flow-Mechanik zusammen. Scrumban funktioniert nur, wenn das Team WIP-Limits als harte Grenzen behandelt.

Nicht ideal für große, komplexe Discovery-Arbeit. Wenn Sie etwas wirklich Unbekanntes entwickeln, erzwingt der Sprint-Rhythmus von Scrum genau die Reflexion und Planung, die explorative Arbeit braucht. Die bedarfsgerechte Planung von Scrumban kann Teams zu lange weitermachen lassen, ohne innezuhalten und zu fragen, ob sie das Richtige bauen.

Schwer messbare Velocity. Da es keine festen Sprints gibt, lassen sich klassische Kennzahlen zur Velocity in agilen Teams nicht direkt anwenden. Teams wechseln stattdessen zu Durchsatz (abgeschlossene Elemente pro Woche) und Durchlaufzeit. Das ist in den meisten Fällen die bessere Kennzahl, erfordert aber ein Umdenken.

So implementieren Sie Scrumban

Schritt 1: Bei Ihrem aktuellen Board beginnen

Gestalten Sie nicht alles auf einmal um. Egal ob Sie von Scrum oder Kanban kommen, behalten Sie Ihre bestehenden Spalten und Ihr Kartenformat bei. Die erste Veränderung ist unsichtbar: Sie wechseln von einer Push-Mentalität (Arbeit an Personen zuweisen) zu einer Pull-Mentalität (Personen ziehen aus der Warteschlange, sobald sie bereit sind).

Schritt 2: WIP-Limits zu aktiven Spalten hinzufügen

Wählen Sie für jede In-Arbeit-Spalte eine konservative Zahl, typischerweise ein bis zwei pro Teammitglied. Sie passen sie nach ein oder zwei Wochen an. Das Ziel ist nicht, die perfekte Zahl zu finden, sondern Flow-Probleme sichtbar zu machen.

Schritt 3: Eine Ready-Warteschlange erstellen

Fügen Sie eine „Ready"-Spalte zwischen Ihrem Backlog und Ihrer ersten aktiven Spalte hinzu. Elemente wandern nur in Ready, wenn sie aufbereitet sind: definiert, geschätzt und wirklich umsetzbar. Das ist Ihr Planungsergebnis. Das Team zieht frei aus Ready, ohne dass ein Planer anwesend sein muss.

Schritt 4: Einen Schwellenwert für den Planungsauslöser festlegen

Entscheiden Sie, wie niedrig die Ready-Warteschlange sinken darf, bevor Sie eine Planungssitzung durchführen. Ein üblicher Ausgangspunkt: planen, wenn Ready unter einen Zwei-Tage-Vorrat fällt. Halten Sie das schriftlich fest. Der Auslöser sollte eine echte Zahl sein, nicht „wenn es sich niedrig anfühlt".

Schritt 5: Schlanke Retrospektiven durchführen

Auch ohne feste Sprints müssen Teams innehalten und fragen, was funktioniert. Planen Sie alle zwei bis vier Wochen eine kurze Retrospektive, oder nach einer festgelegten Anzahl ausgelieferter Elemente. Halten Sie sie kurz, 30 bis 45 Minuten, und fokussiert auf Flow: Was hat uns gebremst, was hat geholfen, und was würden wir als Nächstes ändern.

Nach ein paar Zyklen haben Sie echte Durchsatzdaten. Nutzen Sie diese, um WIP-Limits zu verfeinern, den Planungsauslöser anzupassen und zu erkennen, welche Arten von Arbeit am schnellsten durch das Board laufen. Das ist die Schleife kontinuierlicher Verbesserung im Kern der agilen Methodik.

Scrumban-Beispiele nach Teamtyp

Best Practices

Halten Sie das Board ehrlich. Aktualisieren Sie den Kartenstatus in dem Moment, in dem er sich ändert, nicht beim Stand-up, nicht am Ende des Tages. Ein veraltetes Board ist schlimmer als kein Board, weil es falsches Vertrauen erzeugt.

Behandeln Sie WIP-Limits als Teamvertrag. Einigen Sie sich gemeinsam darauf, schreiben Sie sie aufs Board, und halten Sie einander daran fest. Möchte jemand das Limit überschreiten, ist das ein Gespräch, keine einseitige Entscheidung.

Trennen Sie Dringendes von Geplantem. Fügen Sie dem Board eine kleine „Fast Lane"-Zeile für echte Notfälle hinzu. Begrenzen Sie sie auf jeweils ein Element. Das gibt Vorfällen einen Weg, ohne den Hauptfluss durcheinanderzubringen.

Visualisieren Sie blockierte Arbeit. Nutzen Sie eine Markierung oder Farbe für blockierte Karten, statt sie einfach in „In Arbeit" liegen zu lassen. Blockierte Arbeit, die still innerhalb eines WIP-Limits sitzt, ist unsichtbare Verschwendung.

Messen Sie Durchlaufzeit, nicht Velocity. Verfolgen Sie, wie lange Elemente von Ready bis Fertig brauchen. Die Durchlaufzeit zeigt Ihnen, wie vorhersehbar Ihre Lieferung ist. Sie zu verbessern ist das Hauptziel des Pull-Systems.

Verweisen Sie regelmäßig zurück auf Was ist Scrum und Was ist Kanban. Scrumban leiht sich von beiden, und wenn etwas nicht funktioniert, hilft es, zu den Ursprungsprinzipien zurückzukehren. Oft liegt die Antwort bereits dort.

Erkundet Ihr Team breitere Frameworks für Skalierung, adressiert das Scaled Agile Framework (SAFe) ähnliche Spannungen auf Portfolioebene. Und für Teams, die noch weniger Zeremonie wollen als Scrumban, geht Extreme Programming (XP) einen anderen Weg: mehr Engineering-Praxis, weniger Prozessgerüst.

Häufig gestellte Fragen

Hat Scrumban Sprints?

Standardmäßig nicht. Scrumban ersetzt feste Sprints durch bedarfsgerechte Planung, ausgelöst durch die Warteschlangengröße. Manche Teams behalten dennoch einen lockeren zweiwöchigen Planungsrhythmus als Taktgeber bei, während sie für die Alltagsarbeit auf Flow-Mechanik setzen. Das Framework ist flexibel genug, um Sprints einzubeziehen, wenn sie dem Team dienen.

Gibt es definierte Rollen in Scrumban?

Nein. Scrumban lässt die Rollen Product Owner, Scrum Master und Dev-Team weg, die Scrum vorschreibt. Teams entscheiden selbst, wer den Backlog verantwortet, wer die Planung moderiert und wer das Board pflegt. Viele behalten eine leichte Product-Owner-Rolle, weil jemand weiterhin priorisieren muss. Das Framework schreibt es aber nicht vor.

Ist Scrumban gut für Wartungsteams?

Es ist einer der besten Anwendungsfälle. Wartungsarbeit ist unvorhersehbar, kommt in unterschiedlichen Größen und lässt sich nicht gut in Sprint-Planungszyklen pressen. Das Pull-System und die bedarfsgerechte Planung erlauben Wartungsteams, alles zu bewältigen, was auftaucht, ohne ständig den Umfang gegen eine Sprint-Grenze aushandeln zu müssen.

Wie unterscheidet sich Scrumban davon, einfach „Kanban zu machen"?

Der Hauptunterschied ist Struktur. Reines Kanban hat keine verpflichtenden Zeremonien, keine Planungsauslöser und keine eingebaute Reflexionsschleife. Scrumban fügt eine Ready-Warteschlange, einen Schwellenwert für den Planungsauslöser und optionale Retrospektiven hinzu. Es ist Kanban mit Leitplanken für Teams, denen reiner Flow zu viel dem Zufall überließ.

Welche Kennzahlen sollten Scrumban-Teams verfolgen?

Durchlaufzeit (Zeit von Ready bis Fertig), Durchsatz (abgeschlossene Elemente pro Woche) und Warteschlangengröße sind die drei zentralen Kennzahlen. Ein Cumulative-Flow-Diagramm stellt alle drei in einer Ansicht dar und macht Engpässe offensichtlich. Verzichten Sie auf die Verfolgung der Velocity, außer Sie haben Sprints eingeführt, denn Velocity ist eine sprint-basierte Kennzahl.

Scrumban entwickelt sich weiter, während Teams neue Kombinationen aus den Zeremonien von Scrum und den Flow-Werkzeugen von Kanban finden. Die Beständigkeit des Frameworks beruht auf einer einfachen Idee: den Prozess für die tatsächliche Arbeit optimieren, nicht umgekehrt. Beginnen Sie mit Ihrem aktuellen Board, fügen Sie WIP-Limits hinzu, und beobachten Sie, was die Beschränkungen offenlegen.

Weiterführende Themen

• Was ist Scrum
• Was ist Kanban
• Scrum vs. Kanban
• WIP-Limits
• Cumulative-Flow-Diagramm
• Sprint-Planung
• Velocity in agilen Teams
• Was ist agile Methodik
• Extreme Programming
• Scaled Agile Framework (SAFe)