Methodik

Scrum vs Kanban: Welche Methode passt?

Scrum und Kanban im direkten Vergleich. Wann welches Framework Sinn macht, wo die Unterschiede liegen und warum die meisten Teams beides falsch einsetzen.

Christoph Dietrich2026-05-0612 Min. Lesezeit

Die falsche Frage

"Sollen wir Scrum oder Kanban machen?" - Diese Frage wird in fast jedem Startup irgendwann gestellt. Und fast immer ist sie falsch formuliert. Denn die Antwort hängt nicht davon ab, welches Framework gerade populär ist, sondern von der Art der Arbeit, die Ihr Team tatsächlich macht.

Das Problem: Die meisten Teams wählen Scrum, weil "man das halt so macht". Sie führen Sprints ein, machen Daily Standups und Sprint Retros - und nach drei Monaten stellt jemand fest, dass die Hälfte der Meetings keinen Mehrwert bringt. Oder sie wählen Kanban, weil es "flexibler" klingt, und enden mit einem Board ohne Struktur, auf dem 47 Tickets seit Wochen in "In Progress" stehen.

58%

Der Teams

Nutzen Scrum, aber nur 12% strikt nach Guide

Häufiger

Werden Sprints verlängert als geplant beendet

42%

Der Meetings

Werden als nicht wertschöpfend empfunden

Scrum in 60 Sekunden

Scrum organisiert Arbeit in festen Zeitblöcken (Sprints, meist 2 Wochen). Am Anfang plant das Team was in den Sprint passt. Am Ende wird geliefert und reflektiert.

Die Rollen:

Product Owner - Entscheidet was gebaut wird (Priorisierung)
Scrum Master - Sorgt dafür, dass der Prozess funktioniert
Development Team - Baut das Produkt

Die Events:

Sprint Planning - Was schaffen wir in 2 Wochen?
Daily Standup - 15 Min. tägliche Synchronisation
Sprint Review - Was wurde geschafft? Demo an Stakeholder
Sprint Retro - Was lief gut, was können wir verbessern?

Die Artefakte:

Product Backlog - Geordnete Liste aller Anforderungen
Sprint Backlog - Ausgewählte Items für diesen Sprint
Increment - Das lieferbare Ergebnis am Sprint-Ende

Kanban in 60 Sekunden

Kanban organisiert Arbeit als kontinuierlichen Fluss. Es gibt keine festen Zeitblöcke. Neue Aufgaben werden gezogen, sobald Kapazität frei ist.

Die Prinzipien:

Visualisierung - Alles auf dem Board sichtbar
WIP-Limits - Maximal X Aufgaben gleichzeitig in Arbeit
Flow optimieren - Durchlaufzeit messen und verkürzen
Pull statt Push - Team zieht Arbeit, statt zugewiesen zu bekommen

Keine festen Rollen - Kanban schreibt keine Rollen vor. Es funktioniert mit bestehenden Teamstrukturen.

Keine festen Events - Kein Sprint Planning, kein Sprint Review. Stattdessen: Meetings nach Bedarf, typischerweise ein tägliches Standup und regelmäßige Retrospektiven.

Der direkte Vergleich

Planbarkeit

Scrum: Hohe Planbarkeit. Stakeholder wissen, dass am Ende jedes Sprints ein Ergebnis kommt. Velocity (Teamgeschwindigkeit) wird messbar. Nach 3-4 Sprints kann man relativ genau vorhersagen, wie viel das Team pro Sprint schafft.

Kanban: Geringere Planbarkeit im klassischen Sinn, aber bessere Reaktionsfähigkeit. Durchlaufzeiten sind messbar, aber es gibt kein "Sprint-Ende" an dem geliefert wird. Delivery ist kontinuierlich.

Flexibilität

Scrum: Während eines Sprints soll der Scope nicht verändert werden. Das ist die Stärke (Fokus) und gleichzeitig die Schwäche (Rigidität). Wenn am Dienstag ein kritischer Bug reinkommt, muss er entweder warten oder der Sprint wird abgebrochen.

Kanban: Maximale Flexibilität. Neue Aufgaben können jederzeit priorisiert werden. Ideal wenn Anforderungen sich häufig ändern oder die Arbeit reaktiv ist (Support, Wartung, Ops).

Overhead

Scrum

Vorteile

Klare Struktur gibt Orientierung
Regelmäßige Reflexion durch Retros
Stakeholder bekommen feste Demo-Termine
Velocity macht Fortschritt messbar

Nachteile

4-5 feste Meetings pro Sprint (6-10 Stunden)
Sprint Planning kann zu Schätzungs-Theater werden
Scrum Master als Vollzeit-Rolle oft schwer zu rechtfertigen
Sprint-Grenzen können künstlich wirken

Kanban

Vorteile

Minimaler Overhead - keine Pflicht-Meetings
Sofortige Reaktion auf Prioritätsänderungen
Einfach einzuführen, funktioniert mit jeder Teamstruktur
WIP-Limits verhindern Überlastung

Nachteile

Ohne Disziplin wird das Board zum Chaos
Keine eingebaute Reflexion (Retros müssen aktiv eingeführt werden)
Schwerer, Stakeholdern feste Liefertermine zu nennen
Kann zu 'immer nur das Dringendste' führen

Wann Scrum passt

Scrum funktioniert am besten wenn:

Produktentwicklung mit klarer Vision - Sie bauen ein neues Produkt und haben einen Product Owner der priorisiert
Teams von 5-9 Personen - Klein genug für effektive Meetings, groß genug für Arbeitsteilung
Stakeholder die regelmäßige Updates brauchen - Sprint Reviews geben Transparenz
Komplexe Arbeit die Planung erfordert - Wenn Aufgaben voneinander abhängen
Das Team braucht Struktur - Besonders bei neuen oder unerfahrenen Teams

Typische Scrum-Teams: Produkt-Teams bei SaaS-Unternehmen, Feature-Teams, Teams die ein MVP bauen.

Wann Kanban passt

Kanban funktioniert am besten wenn:

Arbeit die nicht planbar ist - Support-Tickets, Bug-Fixes, Ops-Aufgaben
Kontinuierliche Delivery - Keine künstlichen Sprint-Grenzen nötig
Kleine Teams (2-4 Personen) - Scrum-Overhead wäre zu groß
Arbeit die von außen kommt - Kundenanfragen, externe Abhängigkeiten
Das Team ist erfahren und selbstorganisiert - Braucht weniger Struktur

Typische Kanban-Teams: DevOps, Support, Maintenance-Teams, Agenturen mit wechselnden Kundenaufträgen, Subscription-basierte Entwicklung.

Die dritte Option: Scrumban

In der Praxis nutzen die meisten erfolgreichen Teams eine Mischform. Scrumban kombiniert:

Von Scrum: Regelmäßige Retros, Sprint-ähnliche Planungszyklen
Von Kanban: WIP-Limits, Pull-Prinzip, kontinuierliche Delivery

Das sieht dann so aus:

Planungsmeetings alle 2 Wochen (wie Sprint Planning)
Kein Sprint-Scope-Lock - neue Aufgaben können jederzeit rein
WIP-Limit von 2-3 Items pro Entwickler
Daily Standup (10 Minuten, nicht 15)
Retro alle 2 Wochen
Kein formales Sprint Review - Delivery ist kontinuierlich

Was wir bei proreactware nutzen

Als Subscription-basiertes Entwicklungsteam arbeiten wir mit einer Kanban-Variante mit festen Rhythmen:

Kunden stellen Aufgaben ins Backlog - priorisiert nach ihren Bedürfnissen
WIP-Limit pro Kunde - je nach Plan 1-6 parallele Tasks
Tägliche oder 2-tägliche Updates - Kunden sehen Fortschritt in Echtzeit
Keine Sprints - Aufgaben werden sofort bearbeitet, nicht in 2-Wochen-Blöcken geplant
Wöchentliche interne Retros - Prozessverbesserung im Team

Das funktioniert, weil unsere Kunden Ergebnisse wollen - nicht Meetings. Sie beschreiben was sie brauchen, und wir liefern. Ohne Sprint Planning, ohne Story Points, ohne Velocity-Tracking.

48h

Ø Turnaround

Von Aufgabe bis Review-Ready

Sprint Meetings

Kein Sprint-Overhead für Kunden

94%

Kundenbindung

Über 12 Monate

Die Entscheidungshilfe

Wählen Sie Scrum wenn:

Sie ein internes Produkt-Team haben
Stakeholder regelmäßige Demos erwarten
Das Team 5+ Personen hat
Sie messbare Velocity brauchen
Die Arbeit planbar und zusammenhängend ist

Wählen Sie Kanban wenn:

Arbeit reaktiv oder unvorhersehbar ist
Das Team klein ist (2-4 Personen)
Sie maximale Flexibilität brauchen
Meeting-Overhead minimiert werden soll
Continuous Delivery wichtiger ist als Sprint-Zyklen

Wählen Sie Scrumban wenn:

Sie das Beste aus beiden Welten wollen
Ihr Team erfahren genug ist, Regeln anzupassen
Sie Struktur wollen, aber keine Rigidität

Der häufigste Fehler

Der größte Fehler ist nicht die Wahl des falschen Frameworks - es ist die dogmatische Anwendung. Teams die Scrum "by the book" machen, obwohl ihre Arbeit nicht dafür geeignet ist. Oder Teams die Kanban als Ausrede nutzen, um gar keine Struktur zu haben.

Die besten Teams sind pragmatisch. Sie nehmen was funktioniert, passen es an und werfen weg was nicht hilft. Das Framework ist ein Werkzeug - nicht die Lösung.