Scrumban: wenn der feste Sprint-Takt nicht passt

Scrumban ist eine Mischung aus Scrum und Kanban. In der Praxis ist es fast immer eine Bewegung in eine Richtung: der Übergang von Scrum zu Kanban. Geprägt hat den Begriff Corey Ladas (2008/2009), der ihn als Übergangsweg verstand, nicht als festes Regelwerk. Wer einen Scrumban Guide sucht, der so verbindlich ist wie der Scrum Guide, sucht vergeblich. Genau deshalb setzt jedes Team es etwas anders um.

01 · BasisWas Scrum und Kanban gemeinsam haben

Die meisten ziehen das für sie beste aus Welten und verbinden es. Im Kern bleiben folgende Gemeinsamkeiten (unbewusst) bestehen:

Bei einem entscheidenden Punkt gehen sie aber getrennte Wege, und genau dieser Unterschied beider Methoden macht Scrumban aus.

02 · PrinzipScrum und Kanban kombiniert: weg vom Intervall

Um Scrumban zu verstehen, muss man zuerst sehen, was Scrum mit dem Sprint eigentlich bezweckt. Er ist als geschützter Raum gedacht: ein fester Zeitraum, in dem das Team konzentriert auf ein gemeinsames Ziel hinarbeitet, ohne dass ständig neue Anforderungen dazwischenfunken. Er schafft Fokus, einen verlässlichen Rhythmus und ein Stück Planbarkeit.

Was ein Sprint im Kern aber tut, ist begrenzen. Er ist eine Zeitbox: Er begrenzt die Zeit und damit zugleich die Menge an Arbeit, die in diesen festen Zeitraum passt. Die Steuerung läuft also über die Zeit.

Kanban begrenzt auf einem anderen Weg: über WIP-Limits statt über einen festen Zeitraum. WIP steht für Work in Progress, also für die Anzahl der Aufgaben, die gleichzeitig in Arbeit sind. Es braucht keinen Sprint, um Überlastung zu verhindern, sondern deckelt die parallele Arbeit direkt. Das nimmt die Starrheit des Rahmenwerkes Scrum.

Scrumban bietet genau diesen Wechsel. Es löst die feste Zeitbox auf und ersetzt sie durch die Begrenzung über WIP. Statt alle zwei Wochen einen Sprint zu planen und zu füllen, fließt die Arbeit kontinuierlich weiter.

03 · BoardDas Scrumban-Board: was sich in den Spalten ändert

Sichtbar wird der Unterschied dort, wo die Arbeit hängt. Auf den ersten Blick sieht alles aus wie ein Kanban-Board: Spalten für die Stationen, durch die eine Aufgabe läuft, und über jeder Spalte eine Zahl.

Scrumban verwendet diese Zahl als Deckel. Sie sagt, wie viele Tickets in einer Spalte gleichzeitig liegen dürfen. Ist die Grenze erreicht, wird nichts Neues gezogen, und das Team räumt erst auf, was schon begonnen wurde. Der Workflow wird dadurch nicht schneller getaktet, er wird ruhiger.

04 · VorteileDer eigentliche Gewinn: die Vorteile von Scrumban

Für ein Team, das aus Scrum kommt, ist der spürbarste Vorteil die Entlastung. Einen Sprint mit einem klaren Ziel zu planen, ist Aufwand: Es kostet Zeit, erzeugt Druck und ist ein Stück Organisation, das alle paar Wochen aufs Neue anfällt. Dann die passenden Tickets in genau diesen Zeitraum zu pressen, ist der nächste organisatorische Akt. Zudem gibt es nichts zwischen den Sprints, das bedeutet man hechtet von Ziel zu Ziel, ohne Pause. Ein Marathon aus vielen Sprints.

All das fällt bei Scrumban weg. Es gibt kein Sprint-Ziel, in das alles hineinpassen muss. An ihre Stelle tritt ein einfacheres Prinzip: Die nächste, wichtigste Aufgabe wird gezogen, sobald Kapazität frei ist. Eine neue Aufgabe startet also erst dann, wenn eine begonnene abgeschlossen ist. Für viele Teams ist genau das die Erleichterung, die den Wechsel überhaupt erst attraktiv macht: weniger Termine, weniger Verwaltung und damit mehr Zeit für die eigentliche Arbeit.

Weniger Meetings sind dabei ein Nebeneffekt, den viele unterschätzen. Ohne Planung des nächsten Zeitraums fällt ein wiederkehrendes Meeting ersatzlos weg. Wobei auch Kanban Events, sogenannte Kadenzen liefert. 7 Stück an der Zahl. Sie sind optional, während die 5 Events von Scrum verpflichtend sind.

Scrumban-Teams gewinnen damit vor allem eines: Flexibilität. Wer keine feste Iteration mehr füllen muss, kann auf eine neue Anforderung reagieren, sobald sie auftaucht und Kapazität frei ist. Genau darin liegt die Balance aus Struktur und Flexibilität: genug Ordnung, um den Überblick zu behalten, und genug Spielraum, um flexibel zu bleiben.

Die Effizienz steigt dabei über einen einfachen Hebel. Weniger gleichzeitig offene Arbeit bedeutet weniger Liegezeit, und weniger Liegezeit bedeutet, dass Ergebnisse früher ankommen. Wer effizient arbeiten will, muss also seltener alles gleichzeitig anfassen. Die Produktivität folgt daraus fast von allein.

05 · EignungFür wen sich die Einführung von Scrumban lohnt

Die ehrliche Antwort: für fast jedes Team. Das liegt weniger an Scrumban selbst als an der Art, wie der Wechsel passiert. Er ist ein kleiner, evolutionärer Schritt statt eines großen Umbaus, und genau das senkt die Hürde. Wo ein kompletter Framework-Wechsel auf Widerstand stößt, lässt sich „wir deckeln ab jetzt die parallele Arbeit und ziehen die nächste Aufgabe, wenn Platz ist“ fast nebenbei einführen. Weniger Widerstand, kleinere Schritte, einfachere Change-Projekte: Davon profitiert praktisch jedes Team.

Auch im klassischen Projektmanagement trägt der Gedanke. Ein Team muss nicht agil im Sinne eines Frameworks arbeiten, um von einem Deckel auf der parallelen Arbeit zu profitieren.

Eine Einschränkung gibt es: Im stark skalierten Umfeld, in dem viele Teams an einem Produkt arbeiten, greifen Ansätze wie Nexus oder LeSS oft einfacher als Kanban allein. Aber auch dort gilt der Grundgedanke, lieber in kleinen, verträglichen Schritten zu verändern als mit dem großen Wurf.

Genau hier liegen auch die Nachteile von Scrumban. Wo viel koordiniert werden muss, fehlt der gemeinsame Takt, den ein Sprint mitliefert. Im Gegensatz zu Scrum gibt es keinen Termin, an dem alle automatisch am selben Punkt stehen.

06 · AlltagWas bleibt: die Umsetzung von Scrumban im Alltag

Wichtig ist, was dabei nicht verschwindet. Die bewährten Routinen können bleiben, allen voran die Retrospektive als regelmäßiger Verbesserungspunkt, oft auch das Daily. Und auch die Verantwortlichkeiten bleiben bestehen: Niemand muss Product Owner oder Scrum Master abschaffen, nur weil der feste Takt weicht. Weniger Verwaltung heißt eben nicht weniger Sorgfalt.

Genau das ist die Struktur von Scrumban: Die Elemente von Kanban regeln, wie viel gleichzeitig läuft, und was aus Scrum bleibt, regelt, wie das Team lernt. Scrumban kombiniert damit zwei Antworten auf zwei verschiedene Fragen. Teammitglieder merken den Wechsel vor allem daran, dass die Arbeit ruhiger wird und trotzdem niemand aus dem Blick verliert, woran gerade gearbeitet wird.

Scrumban vereint das Beste aus beiden Welten allerdings nur dann, wenn beide Seiten wirklich verstanden sind. Wer Kanban auf bunte Zettel reduziert und Scrum auf den Sprint, bekommt aus der Kombination auch nichts Besseres.

07 · FAQHäufige Fragen

Eine Frage zum Schluss: Wenn du ehrlich auf eure Sprint-Planung schaust, wie viel davon schafft echten Wert, und wie viel ist Organisation um ihrer selbst willen?

Über den Autor

Stefan Mönk

Gründer der Guided Agile Community (GAC), PSM III-zertifiziert und Dozent an der Universität Hildesheim. Stefan begleitet Praktiker:innen dabei, agiles Wissen iterativ und praxisnah im Berufsalltag zu verankern.

Mehr über Stefan auf LinkedIn