Was ist Scrum?

Scrum ist ein agiles Framework für komplexe Produktentwicklung, definiert im Scrum Guide von Ken Schwaber und Jeff Sutherland. Im Kern besteht Scrum aus drei Rollen, fünf Events und drei Artefakten:

Rollen / Verantwortlichkeiten

Product Owner (verantwortlich für Wert), Scrum Master (verantwortlich für Prozess), Entwickler (verantwortlich für Umsetzung)

Events

Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospektive

Artefakte

Product Backlog, Sprint Backlog, Increment

Was ist Kanban?

Kanban ist eine Methode zur Verbesserung kontinuierlicher Arbeitsflüsse, basierend auf dem Toyota Production System und für Wissensarbeit weiterentwickelt von David J. Anderson. Anders als Scrum schreibt Kanban keine festen Rollen, Events oder Iterationen vor. Im Kern stehen sechs Praktiken:

Visualisiere

den Arbeitsfluss

Limitiere

die parallele Arbeit (WIP-Limits)

Verwalte

den Fluss

Mache

Prozessregeln explizit

Implementiere

Feedback-Schleifen

Verbessere

kollaborativ und entwickle experimentell

Die wichtigsten Unterschiede im Überblick

Bevor wir in den Tiefenvergleich gehen, hier die acht zentralen Unterschiede zwischen Scrum und Kanban auf einen Blick:

Iteration

Scrum arbeitet in festen Sprints (1–4 Wochen). Kanban arbeitet kontinuierlich.

Rollen

Scrum schreibt drei Rollen vor (PO, SM, Dev). Kanban schreibt keine Rollen vor.

WIP-Limits

Scrum begrenzt Arbeit implizit über Sprint-Commitment. Kanban begrenzt explizit pro Spalte.

Veränderung

Scrum führt das gesamte Framework auf einmal ein. Kanban startet mit dem Ist-Zustand und verändert evolutionär.

Planung

Scrum plant pro Sprint. Kanban plant on-demand bei Replenishment.

Metriken

Scrum nutzt Velocity. Kanban nutzt Cycle Time, Lead Time, Throughput.

Eignung

crum für Produktentwicklung. Kanban für Service- und Operations-Arbeit.

Hierarchie zur Veränderung

Scrum erfordert Management-Commitment. Kanban kann von einem einzelnen Team starten.
Praktik / Aspekt Klassischer Prozess Scrum Kanban
Visualisiere Versteckt in Tools, nur für Manager sichtbar Backlog & Sprint Backlog Vollständiges Wertstrom-Board, für alle sichtbar
WIP Limit Keines — alles parallel Sprint-Commitment als implizites Limit Explizite Limits pro Spalte
Process Policies Schwere Dokumentation, oft veraltet Implizit im Framework Explizit, leichtgewichtig, on demand
Verwalte Fluss Nicht im Fokus Implizit über Sprint-Rhythmus Explizit über Metriken
Feedback Loop Lessons Learned am Projektende Retrospektive & Review nach jedem Sprint Mehrere Cadenzen (Daily, Replenishment, Review)
Lernen & Experimente Selten, oft erst nach Scheitern Hängt vom Team / Scrum Master ab Datenbasiert, kontinuierlich
Veränderung Big Bang Projekt Framework wird übernommen Evolutionär, aus dem Bestehenden
Rollen Hierarchisch (PL, TL, etc.) Vorgegeben (PO, SM, Dev) Keine vorgeschrieben
Rhythmus Projekt-Meilensteine Sprints (1–4 Wochen) Kontinuierlicher Fluss
Steuerung Plan & Control Sprint-Ziel WIP & Pull
Fokus Task Completion (Output) Value & Increment (Outcome) Flow & Quality

Vergleichsraster: Wie unterschiedliche Arbeitsweisen typische Praktiken handhaben. Stand: Mai 2026.

Die einzelnen Praktiken & Aspekte der Tabellekurz erklärt

Visualisiere

Im klassischen Projektmanagement findet Arbeit oft in Tools statt, die nur Manager einsehen. Scrum macht Arbeit über Backlog und Sprint Backlog sichtbar. Kanban geht weiter und visualisiert den vollständigen Wertstrom auf einem Board, das für alle zugänglich ist.

WIP Limit

Klassische Projekte haben kein Limit für parallele Arbeit, was zu Multitasking und Unterbrechungen führt. Scrum begrenzt Arbeit implizit durch das Sprint-Commitment. Kanban setzt explizite Limits pro Workflow-Spalte und macht damit Engpässe sichtbar.

Process Policies

Klassische Prozesse sind oft in schweren Dokumentationen verankert, die selten aktuell sind. Scrum verlässt sich auf das implizite Wissen im Framework. Kanban macht Regeln explizit, leichtgewichtig und passt sie bei Bedarf an.

Verwalte Fluss

Klassisches Projektmanagement fokussiert auf Termine, nicht auf Fluss. Scrum sorgt durch den Sprint-Rhythmus implizit für regelmäßigen Fluss. Kanban verwaltet Fluss explizit über Metriken wie Cycle Time und Throughput.

Feedback Loop

Klassische Projekte sammeln Lessons Learned am Projektende, oft zu spät. Scrum etabliert mit Retrospektive und Review feste Feedback-Punkte nach jedem Sprint. Kanban arbeitet mit mehreren Cadenzen unterschiedlicher Frequenz (Daily, Replenishment, Service Delivery Review).

Lernen & Experimente

In klassischen Strukturen wird selten experimentiert; Lernen erfolgt oft erst nach Scheitern. In Scrum hängt die Lernkultur stark vom Team und Scrum Master ab. Kanban macht Lernen datenbasiert und kontinuierlich, basierend auf Flow-Metriken.

Veränderung

Klassische Projekte verändern sich durch Big-Bang-Initiativen. Scrum erfordert die Übernahme des kompletten Frameworks. Kanban startet mit dem Ist-Zustand und verändert evolutionär — ein wichtiger Vorteil in widerstandsbehafteten Organisationen.

Rollen

Klassische Strukturen sind hierarchisch (Projektleiter, Teamleiter etc.). Scrum schreibt drei Rollen vor (Product Owner, Scrum Master, Entwicklungsteam). Kanban schreibt keine Rollen vor und arbeitet mit den bestehenden Verantwortlichkeiten.

Rhythmus

Klassische Projekte folgen festen Meilensteinen. Scrum arbeitet in Sprints von 1–4 Wochen. Kanban arbeitet im kontinuierlichen Fluss ohne festen Rhythmus.

Steuerung

Klassisches Management folgt dem Plan-and-Control-Prinzip. Scrum steuert über das Sprint-Ziel und Sprint-Commitment. Kanban steuert über WIP-Limits und das Pull-Prinzip.

Fokus

Klassische Strukturen fokussieren auf Task Completion (Output). Scrum fokussiert auf Value und Increment (Outcome). Kanban fokussiert auf Flow und Quality.

Welche agile Methode passt zu welchem Team?

Die Wahl zwischen Scrum und Kanban ist seltener eine Frage der Methode und häufiger eine Frage des Arbeitskontexts. Hier sind die Empfehlungen für die häufigsten Team-Typen:

Scrum eignet sich besonders für:

  • Produktentwicklungsteams mit klar abgrenzbaren Zielen pro Iteration. Software-Entwicklung, Hardware-Entwicklung, Marketing-Kampagnen mit definierten Outputs.
  • Teams mit hohem Lernbedarf und wenig Vorerfahrung in agiler Arbeit. Die feste Struktur von Scrum gibt Halt und macht Lernen über mehrere Sprints messbar.
  • Stakeholder mit Bedarf an regelmäßigem Feedback. Sprint Reviews schaffen klare Termine, an denen Auftraggeber den Fortschritt prüfen und Richtung geben können.
  • Teams in einer Organisation, die agile Transformation aktiv vorantreibt. Wenn das Management Scrum einführen will, nutze diesen Rückenwind statt dagegen zu arbeiten.

Kanban eignet sich besonders für:

  • Service- und Operations-Teams mit kontinuierlichem Anfragefluss. IT-Support, Wartung, Customer Service, interne Helpdesks.
  • Teams in widerstandsbehafteten Organisationen. Wenn das Management Veränderung skeptisch sieht, ermöglicht Kanban einen evolutionären Einstieg ohne große Ankündigungen.
  • Bestehende Teams mit eingespielten Strukturen. Wenn Rollen, Verantwortlichkeiten und Prozesse bereits etabliert sind, lässt sich Kanban darüberlegen, ohne diese zu zerstören.
  • Teams mit unvorhersehbarem Anfragevolumen. Wenn die Arbeit nicht in Sprints planbar ist, schafft Kanban über WIP-Limits Stabilität trotz Fluktuation.

Hybride Ansätze: Scrumban und pragmatische Mischformen

In der Praxis nutzen viele Teams nicht reines Scrum oder reines Kanban, sondern Mischformen.

Scrumban

ist die etablierte Hybrid-Methode: Sprint-Struktur aus Scrum kombiniert mit WIP-Limits und Flow-Metriken aus Kanban. Beliebt bei Teams, die Scrum eingeführt haben, aber feststellen, dass Sprints zu starr für ihren Arbeitskontext sind.

Guerilla Scrum

ist ein anderer pragmatischer Ansatz, den vor allem Karrierestarter nutzen: Agile Praktiken werden im Team eingeführt, ohne sie als "Scrum" zu deklarieren. Tägliche Check-ins, Wochenplanung, Retrospektiven — alles inhaltlich Scrum, aber ohne das Etikett, das in vielen Organisationen Widerstand auslöst.

Häufige Fragen zu Scrum vs. Kanban

Ist Kanban einfacher zu lernen als Scrum?

Ja, Kanban hat eine niedrigere Einstiegshürde, weil es keine festen Rollen, Events oder Iterationen vorschreibt. Teams können mit einem einfachen Board und WIP-Limits starten. Die Tiefe von Kanban (Flow-Metriken, evolutionäre Veränderung) erschließt sich aber erst über Zeit.

Kann ein Team von Scrum zu Kanban wechseln?

Ja, der Wechsel ist häufig und sinnvoll, wenn Sprints zu starr werden oder die Arbeit nicht in feste Iterationen passt. Wichtig ist, die Stärken von Scrum (Feedback-Kultur, Stakeholder-Termine) auch im Kanban-Setup zu erhalten — etwa durch regelmäßige Reviews und Retrospektiven.

Können Scrum und Kanban gleichzeitig in einer Organisation existieren?

Ja. Häufig nutzen Produktentwicklungs-Teams Scrum und Operations-Teams Kanban innerhalb derselben Organisation. Wichtig ist, dass die Schnittstellen klar definiert sind — etwa wie Tickets von einem Scrum-Team an ein Kanban-Team übergeben werden.

Brauche ich für Kanban einen Scrum Master?

Kanban schreibt keine Rolle wie Scrum Master vor. In der Praxis übernimmt aber oft eine Person die Verantwortung für Flow-Verbesserung, Coaching und Stakeholder-Kommunikation — vergleichbar mit dem Scrum Master. Im Kanban-Universum ist diese Rolle als "Service Delivery Manager" oder "Flow Manager" bekannt.

Was ist besser für Software-Entwicklung: Scrum oder Kanban?

Für klassische Produktentwicklung mit Feature-orientierter Arbeit: meist Scrum. Für Wartung, Support oder kontinuierliche Releases: meist Kanban. Viele moderne Software-Teams nutzen Scrumban — Sprint-Struktur plus Flow-Metriken.

Welche Zertifizierung sollte ich machen — Scrum oder Kanban?

Wer als Scrum Master oder Product Owner arbeiten möchte, beginnt mit einer Scrum-Zertifizierung (PSM I oder Scrum von A bis Z). Wer im Service- oder Operations-Bereich tätig ist oder evolutionäre Transformation begleitet, profitiert von einer Kanban-Zertifizierung wie KMP. Eine Übersicht findest du im Artikel Scrum-Zertifizierung 2026: Die 7 besten Scrum Master Zertifizierungen im Vergleich.