Was ist Scrumban?

Was Scrumban tatsächlich ist

Scrumban behält die Teile von Kanban und Scrum, die ihr Gewicht tragen, und lässt den Rest weg. Von Kanban übernimmt es das sichtbare Board, den spaltenbasierten Ablauf und eine ausdrückliche Grenze dafür, wie viel gleichzeitig in Arbeit ist — das, was den Fluss lesbar macht. Von Scrum übernimmt es den zeitlich begrenzten Sprint — das, was aus einem Backlog einen Plan macht.

Was es auslässt: tägliche Standups, Grooming-Meetings, Story-Point-Zeremonien, Retrospektiven als Ritual. Das funktioniert für zehn Entwickelnde in einer eingespielten Organisation; es funktioniert nicht für eine Gründerin oder einen Gründer, die oder der am Samstag etwas liefern will.

Der Name stammt von Corey Ladas, dessen Essay und späteres Buch Scrumban beschrieb, wie Scrum-Teams von festen Iterationen zu einem Pull-basierten Fluss übergehen können.

Scrumban vs. Kanban vs. Scrum

Die drei unterscheiden sich vor allem in zwei Punkten: ob Arbeit in festen Zeitfenstern geplant wird und wie viel Prozess das Board umgibt.

Quellen: der Scrum Guide für Sprints, Rollen und Events; der Kanban Guide für Fluss und Grenzen für laufende Arbeit.

Wie sieht ein Scrumban-Board aus?

Ein Scrumban-Board ist ein Kanban-Board, über das ein Sprint gelegt ist. Die Spalten zeigen, wo die Arbeit steht; der Sprint sagt, um welchen Teil des Backlogs es diese Woche geht. Ein minimales Board hat vier Spalten:

• Backlog — alles, was du vielleicht tun wirst. Unten ungeordnet, oben geordnet.
• Todo — was du als Nächstes tun willst. Absichtlich klein: Wenn es knapp wird, ist das das Signal zum Planen.
• Doing — woran gerade jemand (ein Mensch oder ein KI-Agent) arbeitet.
• Done — erledigte Arbeit. Wird am Ende eines Sprints geleert oder archiviert.

Wie richtest du ein Scrumban-Board ein?

1. Lege die vier Spalten an: Backlog, Todo, Doing, Done.
2. Pack alles, was du kennst, ins Backlog. Sortiere nicht alles — sortiere den oberen Teil.
3. Entscheide, wie viel gleichzeitig in Doing sein darf. Für eine Person ein oder zwei Dinge; für ein kleines Team etwa eins pro Person.
4. Wähle eine Sprint-Länge — ein oder zwei Wochen — und schreib ein Ziel in einem Satz dazu. Zieh nur das nach Todo, was diesem Ziel dient.
5. Arbeite im Pull-Prinzip: Wenn etwas in Doing fertig ist, nimm die nächste Karte oben aus Todo. Niemand schiebt anderen Arbeit zu.
6. Plane, wenn Todo knapp wird, nicht nach Kalender. Schau am Sprint-Ende, was erledigt wurde und was nicht, und starte dann den nächsten.

Warum Weft auf Scrumban setzt

Weft gibt es, weil die meisten Aufgabenverwaltungen für eines von zwei Extremen geschnitten sind: entweder eine einsame Todo-App (unendliche Liste, kein Takt) oder eine Agile-Suite für fünfzig Leute (Prozess-Overhead für eine Ein-Personen-Firma). Scrumban sitzt genau in der Mitte — genug Struktur, um wöchentlich oder zweiwöchentlich zu liefern, aber nicht so viel, dass du den Liefertag mit Verwaltung verbringst.

Wie Weft es umsetzt

• Vier voreingestellte Spalten: Backlog, Todo, Doing, Done. Laufende Arbeit begrenzt das, was auf dich wartet, nicht eine Zahl pro Spalte. Der Kanban Guide zählt eine ausdrückliche Regel zur Begrenzung laufender Arbeit zur Definition eines Workflows, damit neue Einträge nur dann hereingezogen werden, wenn Kapazität frei wird.
• Ein aktiver Sprint zur Zeit, mit optionalem Ziel. Sprints sind optional — lass sie weg, wenn reines Kanban passt. Der Scrum Guide definiert Sprints als Events fester Länge von höchstens einem Monat, wobei ein neuer Sprint direkt nach dem Ende des vorherigen beginnt.
• Aufgaben haben Priorität, Schätzung, Fälligkeit und eine optionale Sprint-Zuordnung. Keine Epics, keine Workflows, keine eigenen Felder.
• Die Durchlaufzeit beginnt, wenn eine Aufgabe in eine Spalte mit semantic="doing" wandert, und endet in "done". Die Zahlen entstehen aus ehrlicher Nutzung, nicht aus Story-Point-Arithmetik.

Scrumban mit KI-Agenten

Das Pull-Prinzip macht Scrumban auch für KI-Agenten tauglich. Ein Agent, der über MCP mit Weft verbunden ist, nimmt sich die nächste Karte selbst: start_task beansprucht sie, sodass kein zweiter Agent dieselbe Karte aufgreifen kann, und complete_task schließt sie ab, mit dem, was erledigt wurde, und den Belegen. Braucht ein Agent eine Entscheidung, fragt er dich, statt zu raten — und solange zu viel fertige Arbeit auf dich wartet, beginnen Agenten keine neuen Aufgaben. Das ist das Kanban-Limit für laufende Arbeit, angewandt auf die eine Ressource, die nicht skaliert: deine Aufmerksamkeit.

Wann Scrumban nicht die richtige Methode ist

• Du führst mehrere gleichzeitige Scrum-Teams. Der Scrum Guide setzt ein Scrum-Team bei typischerweise 10 oder weniger Personen an und sagt, dass größere Produkte in mehrere Scrum-Teams aufgeteilt werden sollten, die sich ein Produktziel und ein Product Backlog teilen. Berichte auf Programmebene, gemeinsame Velocity, teamübergreifende Abhängigkeiten — da verdient sich volles Scrum in Jira sein Geld. Der Nexus Guide ist für genau diese Lage geschrieben: mehrere Scrum-Teams, die aus einem einzigen Product Backlog arbeiten, mit zusätzlichen Praktiken, um teamübergreifende Abhängigkeiten sichtbar zu machen und aufzulösen.
• Du machst reinen Support oder Dauerbetrieb. Kein Sprint-Takt nötig — reines Kanban oder ein Ticketsystem passt besser.
• Du brauchst Gantt-Diagramme und Zeitleisten. Scrumban ist auf Sprints ausgerichtet, nicht auf Abhängigkeitsgraphen.

Fragen zu Scrumban