Scrumban: Der pragmatische Hybrid aus Scrum und Kanban

Sprint-Planung, Planning-Poker, Velocity-Tracking, Commitment-Druck – und am Ende des Sprints trotzdem Carryover. Kommt Ihnen das bekannt vor? Willkommen bei Scrumban.

Scrumban ist kein neues Framework. Es ist die ehrliche Antwort auf eine einfache Frage: Was von Scrum funktioniert wirklich – und was ist nur Ritual?

Was ist Scrumban?

Scrumban kombiniert die besten Elemente aus Scrum (strukturierte Meetings, kontinuierliche Verbesserung) mit dem Pull-Prinzip von Kanban (Flow statt Sprints, WIP-Limits statt Commitments).

Die Kernidee: Weg von „2-Wochen-Container mit festem Scope”, hin zum kontinuierlichen Flow. Neue Arbeit wird erst gezogen, wenn wirklich Kapazität frei ist.

Scrum vs. Kanban vs. Scrumban

Aspekt	Scrum	Kanban	Scrumban
Zeitbox	Feste Sprints	Keine	Keine (optional Milestones)
Planung	Sprint Planning	Kontinuierlich	Kontinuierlich
Commitments	Pro Sprint	Keine	Keine
WIP-Limits	Implizit	Explizit	Explizit
Meetings	Daily, Planning, Review, Retro	Minimal	Daily + Retro
Rollen	PO, SM, Dev-Team	Flexibel	Flexibel

WIP-Limits: Der eigentliche Motor

Das Herzstück von Scrumban sind Work-in-Progress-Limits. Sie begrenzen, wie viele Items gleichzeitig in einer Spalte sein dürfen.

Beispiel: Max. 2 Items in „In Progress”

Warum WIP-Limits alles verändern

Weniger Kontextwechsel: Entwickler arbeiten fokussiert an einer Sache
Blocker werden sichtbar: Wenn nichts mehr gezogen werden kann, muss das Problem gelöst werden
Sachen werden fertig: Statt 10 Sachen halb-fertig, 3 Sachen komplett durch
Natürlicher Druck: Das Team löst Probleme, statt sie zu umgehen

Die Realität in vielen Teams:

Sprint A: 15 Stories angefangen, 8 fertig, 7 Carryover
Sprint B: 12 Stories angefangen, 6 fertig, 6 Carryover
Ergebnis: Konstant 6-8 „Zombies” – halb-fertige Arbeit, die niemand abschließt

Mit WIP-Limits:

Woche 1: 3 Stories fertig
Woche 2: 4 Stories fertig
Woche 3: 3 Stories fertig
Ergebnis: Alles wird abgeschlossen. Keine Zombies.

Das Scrumban-Board

Ein typisches Board sieht so aus:

Backlog → Ready → In Progress (WIP: 2) → Review → Done

Optionale Spalte: Blocked – damit Abhängigkeiten nicht „untergehen”

Spalten erklärt

Spalte	Zweck	Typisches WIP-Limit
Backlog	Alle bekannten Aufgaben	Kein Limit
Ready	Priorisiert, bereit zum Start	3-5
In Progress	Aktive Arbeit	2 pro Person
Review	Warten auf Feedback/QA	3
Done	Abgeschlossen	Kein Limit

Was man weglässt (und warum)

Sprint Planning / Planning Poker

Problem: Stunden für Schätzungen, die ohnehin ungenau sind.

Alternative: Backlog wöchentlich nach Business-Value priorisieren. Fertig.

Story Points & Velocity

Problem:

Zu subjektiv („Ist das eine 5 oder eine 8?”)
Leicht zu manipulieren („Wir haben 40 Points geschafft!” – aber nur weil alles aufgebläht wurde)
Erzeugt falsches Gefühl von Kontrolle

Alternative: Echte Flow-Metriken (siehe unten).

Fixe Sprint-Zyklen

Problem:

„End-of-Sprint-Panik” führt zu schlechterer Qualität
Carryover frustriert das Team
Unrealistische Commitments unter Druck

Alternative: Kontinuierlicher Flow. Arbeit wird fertig, wenn sie fertig ist.

Was man behält

Daily Standup

Aber anders. Nicht „Was habe ich gestern gemacht”, sondern:

Was blockiert uns?
Wer braucht Hilfe?
Welches Item bewegt sich heute?

Dauer: 5-10 Minuten. Wirklich.

Retrospektive

Kontinuierliche Verbesserung ist nicht optional. Monatlich oder alle 2 Wochen.

Fokus:

Welche Blocker haben uns aufgehalten?
Wo stockt der Flow regelmäßig?
Was können wir beim Prozess verbessern?

Die richtigen Metriken: Flow statt Points

Cycle Time

Zeit von „In Progress” bis „Done”.

Gut: 2-5 Tage
Schlecht: 2+ Wochen

Lead Time

Zeit von „angefordert” bis „Done”.

Warum wichtig: Zeigt die echte Wartezeit für Stakeholder.

Throughput

Wie viele Items werden pro Woche fertig?

Nutzen: Ehrliche Vorhersage, wann Features fertig sein könnten.

Blocked Time

Wie lange hängt ein Item durchschnittlich fest?

Nutzen: Zeigt systemische Probleme (Abhängigkeiten, fehlendes Wissen, langsame Reviews).

Cumulative Flow Diagram (CFD)

Visualisiert alle Spalten über Zeit. Zeigt sofort:

Wo sich Arbeit staut
Ob WIP-Limits funktionieren
Ob der Flow gleichmäßig ist

Typische Effekte

Teams, die von Scrum zu Scrumban wechseln, berichten:

Ruhigere Arbeitstage: Keine „End-of-Sprint-Panik”
Weniger Carryover: Items werden abgeschlossen statt verschoben
Bessere Qualität: Weniger Bugs durch weniger Rush
Mehr Durchsatz: 20-30% mehr fertige Items (je nach Ausgangslage)
Bessere Vorhersagbarkeit: Echte Daten statt Schätzungen

Beispiel-Vergleich

Metrik	Klassisch Scrum	Scrumban
Bugs pro Feature	1.4	0.9
Carryover pro Sprint	4-6 Items	0 (kein Sprint)
Cycle Time	8-12 Tage	3-5 Tage

Hinweis: Das sind berichtete Werte aus der Praxis, keine Garantie.

Die größte Gefahr: Der Tunnel-Effekt

Symptom: Jemand arbeitet wochenlang an einem Monster-Task. Das Board zeigt „In Progress”, aber niemand weiß, wie weit es wirklich ist.

Gegenmittel

Tasks klein schneiden: Max. 2 Wochen pro Ticket. Alles Größere ist ein Epic und muss zerlegt werden.
Kleine Demos: Regelmäßige Checkpoints, auch für unfertige Arbeit
WIP-Limit = 1: Für kritische Bereiche
Visuelle Indikatoren: Items, die zu lange in einer Spalte sind, werden farblich markiert

Wann Scrumban nicht passt

Scrumban ist kein Allheilmittel. Weniger geeignet bei:

Harten regulatorischen Deadlines: Wenn ein Termin wirklich fix ist
Verträgen mit festem Scope/Termin: Klassisches Projektgeschäft
Starken Multi-Team-Abhängigkeiten: Wenn Teams synchronisiert liefern müssen
Stakeholdern, die Sprint-Commitments erwarten: Change Management nötig

Alternative: Hybrid-Ansatz

Flow im Alltag, aber leichte Timeboxen für echte Milestones.

Beispiel: Kontinuierlicher Flow, aber alle 4 Wochen ein „Demo Day” für Stakeholder.

Minimaler Start: Das Template

Sie wollen Scrumban ausprobieren? Hier ist der kleinste sinnvolle Start:

Board

Backlog | Ready (3) | In Progress (2) | Review (3) | Done

Rituale

Frequenz	Aktivität	Dauer
Täglich	Standup (Blocker + Flow)	10 min
Wöchentlich	Backlog-Priorisierung	30 min
Monatlich	Flow-Metriken Review + Retro	60 min

Erste Schritte

Aktuelles Board visualisieren: Wo steht alles gerade?
WIP-Limits setzen: Start mit 2 pro Person in „In Progress”
Metriken aufsetzen: Cycle Time tracken (geht auch manuell)
Sprint-Commitment auslaufen lassen: Keine neuen Sprints starten
Nach 4 Wochen: Erste Retro mit Flow-Fokus

Der pragmatische Mittelweg

Scrumban ist Scrum ohne den Ballast. Kanban mit etwas Struktur. Der pragmatische Mittelweg für Teams, die echte Ergebnisse wichtiger finden als perfekte Prozesse.

Die Frage ist nicht „Scrum oder Kanban?”. Die Frage ist: Was hilft unserem Team, bessere Software zu liefern?

Und wenn die Antwort ist: „Weniger Meetings, mehr Flow, echte Metriken” – dann ist Scrumban einen Versuch wert.

Praxis-Kurs: Scrumban erfolgreich einführen

Sie möchten Scrumban in Ihrem Team einführen und brauchen konkrete Anleitungen, Templates und Best Practices?

👉 Scrumban in der Praxis – Der komplette Implementierungs-Kurs

Im Kurs lernen Sie:

Schritt-für-Schritt-Anleitung für den Wechsel von Scrum zu Scrumban
Board-Templates und Tool-Setups (Jira, Linear, Notion)
WIP-Limits richtig setzen und anpassen
Flow-Metriken messen und interpretieren
Häufige Fehler vermeiden
Change Management: Wie Sie Stakeholder überzeugen

Wann Scrumban die richtige Wahl ist

Bei stabilen Teams mit gemischtem Workload: Features + Maintenance.
Bei Teams mit Scrum-Ermüdung: Sprint-Stress reduzieren.
Bei Teams mit Kanban-Strukturschwäche: Mehr Struktur dazugeben.

Wann nicht

Bei wirklich neuen Teams: Erst eine Methode lernen.
Bei sehr explorativen Projekten: Discovery-Phasen brauchen weniger Prozess.
Bei reinen Support-Teams: Reines Kanban oft ausreichend.

Realistische Einführungs-Schritte

Phase 1 (Wochen 1–4): Bestehende Prozesse dokumentieren.
Phase 2 (Wochen 5–12): Schrittweise Scrumban-Elemente einführen.
Phase 3 (ab Monat 3): Optimierung anhand Metriken.

Tooling

Jira: Funktioniert für Scrumban, aber komplex.
Linear: Modern, gut für Scrumban-Teams.
GitHub Projects: Einfach, für kleine Teams.