Scrumban für KI-Projekte — Sprint-Rhythmus und kontinuierlichen Flow verbinden

Wer Scrum und Kanban nur als zwei Boards mit unterschiedlich bewegten Karten betrachtet, verpasst den eigentlichen Unterschied. Beide Methoden organisieren Arbeit, aber sie organisieren vor allem Zeit, Aufmerksamkeit und Veränderung unterschiedlich. Scrum schafft einen Rhythmus, in dem ein Team für einen begrenzten Zeitraum eine ausgewählte Menge Arbeit schützt. Kanban schafft einen Fluss, in dem neue Arbeit dann nachrückt, wenn Kapazität frei wird.

Gerade in KI-Projekten werden häufig beide Logiken gleichzeitig benötigt. Ein Feature, ein Prototyp oder eine definierte Integrationsstufe braucht möglicherweise mehrere Tage konzentrierte Arbeit, bevor eine sinnvolle Bewertung überhaupt möglich ist. Gleichzeitig kommen neue Erkenntnisse, Rückmeldungen, Datenprobleme, Content-Aufgaben, Fehler, Modelltests oder operative Anforderungen fortlaufend hinzu. Wird alles in Sprints gezwungen, entsteht Rückstau und unnötige Starrheit. Wird alles in einen offenen Flow geworfen, verliert das Team leicht den Fokus und beginnt ständig Neues, bevor Wichtiges belastbar abgeschlossen ist.

Genau an dieser Stelle entsteht in der Praxis die Brücke zu Scrumban. Scrum und Kanban werden dabei bewusst nicht als Glaubensrichtungen behandelt. Nach der Gegenüberstellung gilt ausdrücklich: Keine der beiden Methoden ist die „goldene Regel", die Wahl hängt vom Projekt, von der Phase und von der Aufgabe ab. In der Praxis zeigt sich immer wieder, dass die meisten Empfehlungen ohnehin auf Mischformen hinauslaufen — eine Mischung aus Scrum und Kanban, die als „Scrumban" bezeichnet wird.

Damit wird Scrumban für diese Serie nicht als starres Framework verstanden, das exakt nach einem externen Regelbuch umgesetzt werden müsste. Es ist zunächst eine Projektlogik aus der Praxis: Wo brauche ich einen geschützten Sprint-Rhythmus, wo einen kontinuierlichen Pull-Flow, und wie verhindere ich, dass beide Systeme sich gegenseitig sabotieren?

Zwei Uhren im selben Projekt

Scrum und Kanban unterscheiden sich vor allem durch die Art, wie Arbeit aufgenommen und geschützt wird. Scrum ist ein sprintbasierter Ablauf: planen, bauen, testen, reviewen. Eine ausgewählte Menge Arbeit wird für einen Zeitraum fokussiert bearbeitet. Neue Anforderungen sollen den laufenden Sprint nicht ständig neu zusammensetzen. Am Ende steht ein Review; je nach Ergebnis wird freigegeben, angepasst oder ein weiterer Sprint geplant.

Kanban ist dagegen ein kontinuierlicher Prozess. Arbeit wandert durch Zustände, und neue Arbeit wird nachgezogen, wenn Kapazität frei wird. Der Fluss orientiert sich damit stärker an Priorität, Engpässen und verfügbarer Bearbeitungskapazität als an einem im Voraus geschlossenen Arbeitspaket.

Beide Logiken lösen ein anderes Problem. Der Sprint schützt Konzentration und Commitment. Der Flow schützt Beweglichkeit und Durchsatz.

Diese Tabelle zeigt den eigentlichen Nutzen einer hybriden Logik: Es geht nicht darum, zwei Methoden nebeneinander zu kleben. Es geht darum, zwei unterschiedliche Arten von Zeit sinnvoll zu koppeln.

Feature-Entwicklung ist nicht dasselbe wie Content-Produktion

Ein besonders anschauliches Beispiel: Für ein Projekt wurde Scrum für Feature-Entwicklung und MVP-Logik vorgeschlagen, weil dort ein klarer Sprint-Rhythmus sinnvoll war. Die anschließende Content-Produktion rund um den Launch sollte dagegen über Kanban laufen, weil eine laufende Pipeline und schnelle Iteration besser zu diesem Arbeitscharakter passten.

Dieser Unterschied ist für KI-Projekte enorm wichtig. Ein Feature hat häufig einen Zustand, bei dem mehrere abhängige Schritte gemeinsam sinnvoll abgeschlossen werden müssen. Eine Schnittstelle, ein Agentenworkflow oder ein Retrieval-Modul kann nicht nach jedem kleinen Zwischenschritt als fertiges Ergebnis betrachtet werden. Man braucht einen begrenzten Zeitraum, in dem das Team das Arbeitspaket gegen Störungen schützt, es baut, testet und anschließend bewertet.

Content, Support, kleine Datenkorrekturen oder wiederkehrende operative Aufgaben verhalten sich anders. Sie kommen laufend herein, unterscheiden sich in Größe und Priorität und müssen nicht unbedingt in ein künstliches Zweiwochenpaket gepresst werden. Hier ist ein kontinuierlicher Flow häufig natürlicher.

Scrumban wird damit interessant, wenn verschiedene Arbeitsarten innerhalb desselben Projekts unterschiedliche Takte brauchen.

Der Sprint ist ein Schutzraum, kein Kalender-Ritual

Ein häufiger Fehler besteht darin, Scrum auf die Existenz eines zweiwöchigen Kalenders zu reduzieren. Entscheidend ist jedoch die Schutzfunktion des Sprints. Das Team wählt relevante Arbeit aus und konzentriert sich darauf. Neue Anforderungen werden nicht automatisch zur sofortigen Umpriorisierung.

Für KI-Projekte ist diese Schutzfunktion besonders wertvoll, weil KI-Arbeit eine gefährliche Eigenschaft besitzt: Neue Möglichkeiten erscheinen schneller, als alte sauber validiert werden können. Während ein Agentenworkflow gebaut wird, entdeckt jemand ein neues Modell. Während ein Modell getestet wird, entsteht eine neue Tool-Idee. Während eine Datenpipeline stabilisiert wird, liefert ein Deep Research drei zusätzliche Architekturvarianten.

Wenn jede neue Möglichkeit sofort in laufende Arbeit eindringt, entsteht keine Agilität. Es entsteht permanente Kontextumschaltung.

Ein guter Sprint definiert deshalb einen temporären Entscheidungsschutz. Für eine begrenzte Zeit gilt: Dieses Ziel, diese Hypothese oder dieses Lieferobjekt wird jetzt belastbar bearbeitet. Neue Ideen verschwinden nicht. Sie wandern in einen geordneten Eingangskanal und werden später bewertet.

Genau hier beginnt die Verbindung mit Kanban.

Der Flow ist ein Druckventil, kein ungefilterter Eingang

Kanban ist ein kontinuierlicher Prozess mit Pull-Logik und Work-in-Progress-Begrenzung. Für diese Serie ist an dieser Stelle vor allem der Pull-Gedanke relevant: Neue Arbeit wird nicht deshalb begonnen, weil sie existiert, sondern weil das System Kapazität hat, sie sinnvoll aufzunehmen.

Das ist ein großer Unterschied.

Ein offener Aufgabenpool ohne Kapazitätslogik ist kein Flow-System. Er ist eine Warteschlange mit schlechtem Gewissen.

Im Scrumban-Modell bekommt der kontinuierliche Kanal daher eine klare Aufgabe. Er nimmt Arbeit auf, die kurzfristig, unabhängig oder operativ bearbeitbar ist, ohne den geschützten Fokus eines Sprints ständig zu zerstören. Kleine Korrekturen, Content-Aufgaben, Dokumentationspflege, klar begrenzte Tests oder Supportfälle können dort nach Priorität und Kapazität fließen.

Die tiefe Behandlung von WIP-Limits, Rolling Waves und kontrollierbaren Arbeitspaketen folgt später in dieser Serie. Für Scrumban reicht zunächst das zentrale Prinzip: Flow darf nur so viel Arbeit aufnehmen, wie tatsächlich weiterbewegt werden kann.

Die wichtigste Scrumban-Grenze: Was darf den Sprint unterbrechen?

Die Qualität eines hybriden Systems zeigt sich nicht daran, wie elegant das Board aussieht. Sie zeigt sich an der Grenzregel zwischen Sprint und Flow.

Wenn jede neue Flow-Aufgabe einen Sprint unterbrechen darf, existiert faktisch kein Sprint. Wenn dagegen kein dringender Befund einen Sprint beeinflussen darf, wird der Sprint zur Abschottung von Realität.

Deshalb braucht ein KI-Projekt eine explizite Unterbrechungslogik. Eine neue Modellidee ist normalerweise kein Grund, laufende Arbeit zu stoppen. Ein hübscher Optimierungsvorschlag auch nicht. Ein Sicherheitsproblem, ein fehlerhaftes Datenfundament oder eine Evidenz, die die Kernannahme des laufenden Sprints widerlegt, kann dagegen eine echte Eskalation sein.

Diese Unterscheidung lässt sich professionell als Frage formulieren:

Verändert die neue Information nur unsere Optionen — oder zerstört sie die Gültigkeit der aktuellen Arbeit?

Nur im zweiten Fall ist eine Sprintunterbrechung ernsthaft zu prüfen.

So bleibt das Projekt offen für Evidenz, ohne sich von jedem neuen Impuls treiben zu lassen.

User Stories, Review und die Logik des „kleinen lieferbaren Stücks"

Eine Funktion wird in kleinere beschreibbare Arbeitseinheiten zerlegt; die Schwierigkeit beziehungsweise der Aufwand wird grob eingeschätzt; nach der Umsetzung folgt ein Review und Feedback entscheidet mit darüber, ob das Ergebnis angenommen, verändert oder weiterentwickelt wird.

Das ist deshalb wichtig, weil es Scrumban vor einem verbreiteten Missverständnis schützt. „Kleine Aufgaben" sind nicht automatisch gute Arbeitseinheiten. Entscheidend ist, ob ein Stück Arbeit prüfbar und anschlussfähig ist.

Für ein KI-Projekt könnte eine schlechte Einheit lauten: „Agent verbessern." Sie ist offen, unmessbar und erzeugt kein klares Review.

Eine bessere Einheit wäre: „Der Recherche-Agent soll aus zehn freigegebenen Quellen einen strukturierten Entwurf erzeugen, der jede zentrale Behauptung auf eine Quelle zurückführen kann; anschließend wird die Rückverfolgbarkeit an drei Testfällen geprüft."