Sie haben es mit Tabellenkalkulationen, E-Mail-Threads und vielleicht sogar mit einer Zauberkugel versucht, und trotzdem geraten Projekte ins Stocken, Prioritäten geraten in Konflikt und Fristen schleichen sich an. Wenn Ihnen das bekannt vorkommt, ist es Zeit, Ihre Strategie zu überdenken und zwei bewährte Systeme in Betracht zu ziehen: Kanban und Scrum. Beide gehören zum übergeordneten agilen Rahmenwerk für Produktentwicklung und Projektmanagement und zielen darauf ab, Klarheit ins Chaos zu bringen.
Scrum gibt Ihnen Sprints an die Hand, kurze, feste Intervalle, in denen eine klar definierte Gruppe (Product Owner, Scrum Master, Entwicklungsteam) eine festgelegte Anzahl von Aufgaben bearbeitet, um sie anschließend in einem Sprint Review zu überprüfen und anzupassen. Es ist ein Rhythmus mit Leitplanken.
Kanban gibt Ihnen ein Board, Spalten für jede Arbeitsphase, Begrenzungen dafür, wie viel Sie gleichzeitig beginnen, und den Fokus auf einen kontinuierlichen Arbeitsfluss. Es gibt keine festgelegten Rollen, Ihr Team passt die Richtlinien an, während es dazulernt.
In diesem Artikel werden wir beide Rahmenwerke untersuchen, ihre Rollen, Rituale und Werkzeuge vergleichen und Ihnen helfen, dasjenige auszuwählen, das zum Rhythmus Ihres Teams passt.
Was ist Scrum?
Scrum strukturiert die Arbeit in zeitlich begrenzte Intervalle, in der Regel zwei bis vier Wochen, damit Teams kontinuierlich kleine Updates liefern können. Das Ziel ist einfach: grosse Projekte in überschaubare Einheiten aufteilen, den Fortschritt regelmässig überprüfen und sich schnell anpassen.
Definierte Rollen
- Product Owner: Verantwortet das Backlog, legt Prioritäten fest und beantwortet Fragen zu Anforderungen.
- Scrum Master: Coacht das Team in Scrum-Praktiken, beseitigt Hindernisse und schützt das Team vor Ablenkungen.
- Entwicklungsteam: Eine funktionsübergreifende Gruppe von Teammitgliedern, die Aufgaben entwirft, entwickelt, testet und liefert.
Diese Rollen sind nicht verhandelbar, keine Mischrollen, kein „Teilzeit-Scrum Master“. Klare Verantwortlichkeiten stellen sicher, dass alle Beteiligten rechenschaftspflichtig bleiben.
Zentrale Artefakte
- Product Backlog: Die Hauptliste mit Funktionen, Fehlerbehebungen und technischen Aufgaben, geordnet nach Wert und Dringlichkeit.
- Sprint Backlog: Ein Teil des Product Backlogs, der für den aktuellen Sprint ausgewählt wird, inklusive Sprint-Zielen und geschätztem Aufwand.
- Inkrement: Die Summe aller als „Erledigt“ markierten Arbeitselemente am Ende eines Sprints. Jedes Inkrement muss der teaminternen Definition von „Erledigt“ entsprechen.
Zentrale Ereignisse
- Sprint-Planung: Entscheidung darüber, was in den Sprint aufgenommen wird. Der Product Owner stellt priorisierte Elemente vor; das Entwicklungsteam verpflichtet sich je nach Kapazität.
- Tägliches Scrum: Ein 15-minütiges Stand-up. Jedes Teammitglied beantwortet: Was habe ich gestern gemacht? Was mache ich heute? Gibt es Hindernisse?
- Sprint Review: Vorstellung des Inkrements für Stakeholder, Einholen von Feedback und Aktualisierung des Product Backlogs.
- Sprint-Retrospektive: Reflexion über den Sprint-Prozess, Ermittlung von Verbesserungen und Planung von Änderungen für den nächsten Sprint.
Rhythmus und Fälligkeitstermine
Sprints sorgen für Regelmässigkeit. Da sie eine feste Länge haben, entsteht ein vorhersehbarer Rhythmus: Sie wissen genau, wann das nächste Sprint Review stattfindet und wann Fälligkeitstermine fixiert sind. Das erleichtert Prognosen und gibt dem Team einen klaren „Herzschlag“.
Kennzahlen
- Velocity: Durchschnittlich abgeschlossene Story Points (oder andere Einheiten) pro Sprint. Wird zur Prognose zukünftiger Arbeiten verwendet.
- Burndown-Chart: Verfolgt die verbleibende Arbeit innerhalb eines Sprints und zeigt, ob das Team auf Kurs ist.
Scrum eignet sich besonders, wenn Sie Struktur, definierte Rollen, regelmässige Kontrollpunkte und klare Fälligkeitstermine benötigen. Es ist keine Zauberei, aber es bringt einen disziplinierten Arbeitsfluss, den viele Teams als unverzichtbar empfinden.
Was ist Kanban?
Kanban ist eine agile Methode, die sich auf die Visualisierung von Arbeitselementen und das Management des Arbeitsflusses konzentriert. Ursprünglich in der Fertigung entwickelt, wurde sie inzwischen für die Software- und Produktentwicklung angepasst. Im Gegensatz zu Scrum erfordert Kanban keine Iterationen mit fester Länge oder vorgeschriebene Rollen.
Grundprinzipien
Arbeit visualisieren
- Verwenden Sie ein Kanban-Board mit Spalten (z. B. „Backlog“, „In Bearbeitung“, „Review“, „Erledigt“)
- Jede Karte steht für ein Arbeitselement wie eine Funktion, eine Fehlerbehebung oder eine Aufgabe
Work in Progress (WIP) begrenzen
- Legen Sie klare Grenzen dafür fest, wie viele Karten sich gleichzeitig in einer Spalte befinden dürfen
- Verhindert eine Überlastung des Entwicklungsteams und macht Engpässe sichtbar
Arbeitsfluss managen
- Verfolgen Sie, wie lange Karten sich in jeder Phase befinden (Zykluszeit)
- Ziel ist ein kontinuierlicher, vorhersehbarer Durchsatz statt sprunghafter Aktivität
Regeln explizit machen
- Definieren Sie Eintritts- und Austrittskriterien für jede Spalte
- Dies schafft Klarheit für Teammitglieder und reduziert Unklarheiten
Feedback-Schleifen einführen
- Führen Sie regelmässige Reviews durch (z. B. wöchentlich oder zweiwöchentlich), um den Arbeitsfluss und die Prozesse zu überprüfen
- Passen Sie WIP-Grenzen oder Richtlinien anhand von Daten und Team-Feedback an
Kontinuierliche Verbesserung
- Verwenden Sie Metriken wie die Durchlaufzeit (Zeitspanne von der Anforderung bis zur Lieferung), um Verbesserungsbereiche zu identifizieren
- Ermutigen Sie jedes Teammitglied, Vorschläge zur Optimierung des Prozesses einzubringen
Kanban-Boards und Arbeitselemente
Ein typisches Kanban-Board enthält Spalten, die den Phasen Ihres Workflows entsprechen. Karten bewegen sich von links nach rechts:
- Arbeitselemente: Jede Karte enthält eine Beschreibung, eine zugewiesene Person (Teammitglied) und bei Bedarf Fälligkeitsdaten.
- Swimlanes: Optionale horizontale Zeilen für unterschiedliche Prioritätsstufen oder Arbeitstypen (z. B. „Dringend“, „Wartung“, „Neue Funktion“).
Kennzahlen
- Zykluszeit: Zeitspanne, die eine Karte von „In Bearbeitung“ bis „Erledigt“ benötigt.
- Durchlaufzeit: Zeitspanne vom Eintritt der Karte ins Backlog bis zur Fertigstellung.
- Durchsatz: Anzahl der in einem bestimmten Zeitraum abgeschlossenen Karten.
Flexibilität und Rollen
Kanban schreibt keine Rollen wie Product Owner oder Scrum Master vor. Teammitglieder teilen sich die Verantwortung für das Ziehen von Arbeit, die Überprüfung von Richtlinien und die Förderung von Verbesserungen. Sie können Rollen nach Bedarf einführen, aber die Methode lebt von ihrer Anpassungsfähigkeit.
Varianten der Kanban-Methode
- Kanban für Ops: Fokus auf schnelle Reaktion auf eingehende Probleme, ideal für Support-Teams.
- Evolutionäre Veränderung: Starten Sie mit Ihrem aktuellen Prozess, ergänzen Sie ein Kanban-Board und entwickeln Sie es weiter.
Kanban eignet sich besonders, wenn sich Prioritäten unvorhersehbar ändern, Arbeitselemente unterschiedlich gross sind und Sie einen klaren Überblick über den Arbeitsfluss benötigen, ohne den Aufwand fester Sprintlängen. Kontinuierliche Verbesserung ist dabei fest integriert und ermöglicht es Ihnen, Ihren Prozess Schritt für Schritt zu optimieren.
Wesentliche Unterschiede zwischen Kanban und Scrum
Nachdem wir beide Methoden beschrieben haben, fassen wir nun ihre wichtigsten Unterschiede zusammen, ohne jedes Detail zu wiederholen.
Struktur und Rollen
Scrum bietet klare Leitplanken: einen Product Owner, der das Backlog verantwortet, einen Scrum Master, der den Prozess überwacht, und ein Entwicklungsteam, das in Sprints liefert. Diese Rollen bleiben während des gesamten Sprints unverändert. Kanban hingegen verzichtet auf vorgegebene Rollen. Jedes Teammitglied kann Arbeit ziehen, Richtlinien anpassen oder Kolleginnen und Kollegen coachen, vorausgesetzt, es ist geklärt, wer was übernimmt. So kann Verantwortung gleichmässiger verteilt werden.
Rhythmus und Planung
Sprints sind feste Intervalle mit definierten Zielen und Fälligkeitsdaten. Diese Planbarkeit wirkt wie ein Herzschlag. Kanban ersetzt das durch einen kontinuierlichen Arbeitsfluss: Elemente bewegen sich unabhängig über das dauerhafte Kanban-Board. Fälligkeitsdaten werden pro Karte festgelegt, nicht pro Sprint, und Prioritäten können jederzeit neu geordnet werden, solange die WIP-Grenzen eingehalten werden.
Board-Management
Bei Scrum wird das Board mit jedem Sprint zurückgesetzt: „Erledigt“-Elemente werden entfernt, neue hinzugefügt, und der Fortschritt wird bis zum nächsten Reset verfolgt. Kanban-Boards hingegen bleiben bestehen. Die Spalten bleiben erhalten, und Karten durchlaufen das Board bis zur Fertigstellung. Diese fortlaufende Darstellung erleichtert es, lang andauernde Arbeiten oder wiederkehrende Engpässe zu erkennen, ohne das Board alle paar Wochen neu aufzubauen.
Umgang mit Veränderungen
Sprint-Grenzen schützen die Konzentration, indem sie den Umfang während des Sprints einfrieren. Wenn ein dringender Fehler auftritt, muss bis zum nächsten Sprint gewartet oder eine Ausnahme gemacht werden. Bei Kanban bleibt alles offen: Karten können jederzeit hinzugefügt, entfernt oder neu priorisiert werden, solange die WIP-Grenzen nicht überschritten werden. Diese Flexibilität ist besonders hilfreich bei unvorhersehbarem Arbeitsaufkommen.
Erfolgsmessung
Scrum-Teams messen die Velocity (Story Points pro Sprint) und nutzen Burndown-Charts, um zu prüfen, ob das Sprint-Ziel erreicht wird. Diese Metriken helfen bei Prognosen. Kanban-Teams konzentrieren sich auf Flow-Metriken: Zykluszeit (von „In Bearbeitung“ bis „Erledigt“), Durchlaufzeit (von der Anforderung bis zur Lieferung) und Durchsatz (abgeschlossene Elemente pro Zeitraum). Diese Zahlen zeigen, wie reibungslos die Arbeit läuft und wo Optimierungspotenzial besteht.
Rhythmus der kontinuierlichen Verbesserung
Beide Rahmenwerke legen Wert auf Lernen. Bei Scrum geschieht das in der Sprint-Retrospektive am Ende jedes Zyklus. Bei Kanban verteilt sich das Feedback auf regelmässige Verbesserungsmeetings oder spontane Gespräche. Richtlinien und WIP-Grenzen werden angepasst, sobald Daten oder Bauchgefühl auf Probleme hinweisen.
Kurz gesagt: Wenn Sie zeitlich begrenzte Leitplanken, klar definierte Rollen und kalenderbasierte Fälligkeitstermine benötigen, passt Scrum zu Ihnen. Wenn Sie hingegen Flexibilität, eine dauerhafte Sicht auf Arbeitselemente und die Möglichkeit brauchen, jederzeit Kursänderungen vorzunehmen, ist Kanban vermutlich die bessere Wahl.
Wann sollte Scrum verwendet werden?
Wählen Sie Scrum, wenn Ihr Projekt von klaren Meilensteinen, regelmässigen Kontrollpunkten und eindeutig definierten Rollen profitiert. Wenn Sie einen Product Owner benötigen, der das Backlog priorisiert, einen Scrum Master, der das Team vor Ablenkungen schützt, und ein Entwicklungsteam, das sich auf den Umfang eines Sprints konzentriert, bietet Scrum die nötige Struktur.
Scrum eignet sich besonders gut für Produktentwicklungen, bei denen Funktionen aufeinander aufbauen. Sie können eine Serie von Sprints planen, jeder sogenannte Sprint dauert zwei bis vier Wochen, mit festen Fälligkeitsdaten, die mit Veröffentlichungsterminen oder Reviews durch Stakeholder übereinstimmen. Das Sprint Review bietet einen formellen Moment, um Arbeitselemente vor Stakeholdern zu präsentieren, Feedback einzuholen und das Product Backlog für den nächsten Sprint zu verfeinern.
Teams, die auf Vorhersehbarkeit setzen, neigen ebenfalls zu Scrum. Die Velocity (durchschnittlich abgeschlossene Story Points pro Sprint) ermöglicht es, abzuschätzen, wie viele Sprints für bestimmte Arbeitselemente benötigt werden. Wenn das Einhalten von Terminen entscheidend ist, etwa für einen Marketing-Launch, eine Compliance-Frist oder ein wichtiges Produkt-Release, bieten Sprint Reviews verlässliche Meilensteine.
Scrum-Rahmenwerke helfen auch neuen Scrum-Teams dabei, agile Praktiken zu erlernen. Die definierten Zeremonien wie Sprint-Planung, tägliches Scrum, Sprint Review und Sprint-Retrospektive schaffen einen wiederholbaren Rhythmus. Dieser Rhythmus kann Teams Orientierung geben, die kontinuierliche Verbesserung noch nicht verinnerlicht haben, und ihnen einen sicheren Rahmen bieten, um Prozesse zu hinterfragen und anzupassen.
Kurz gesagt: Wenn Ihre Arbeit einen strengen Sprint-Rhythmus, vorhersehbare Fälligkeitsdaten und formelle Rollen wie Product Owner und Scrum Master erfordert, ist Scrum wahrscheinlich die bessere Wahl im Vergleich zu kanban oder scrum.
Wann sollte Kanban verwendet werden?
Kanban ist die richtige Wahl, wenn Arbeit unvorhersehbar eintrifft, Prioritäten sich häufig ändern oder Aufgaben stark in ihrer Grösse variieren. Wenn Ihr Team Support-Tickets, Wartungsanfragen oder ungeplante Fehlerbehebungen bearbeitet, ermöglicht der kontinuierliche Arbeitsfluss von Kanban, dringende Arbeiten aufzunehmen, ohne auf den nächsten Sprint warten zu müssen.
Sie richten ein Kanban-Board ein, definieren Phasen, die Ihrem Prozess entsprechen, und legen klare Work-in-Progress-Grenzen (WIP) fest. Das verhindert Überlastung: Ist die Spalte „In Bearbeitung“ voll, werden bestehende Karten zuerst abgeschlossen, bevor neue begonnen werden. Während die Karten nach rechts wandern, verfolgen Sie Zykluszeit und Durchlaufzeit, um Engpässe zu erkennen und den Arbeitsfluss zu optimieren.
Kanban eignet sich besonders, wenn Sie:
- Flexibilität bei Fälligkeitsdaten benötigen. Statt Termine für einen Sprint festzulegen, versehen Sie einzelne Arbeitselemente mit Fälligkeitsdaten und passen diese bei Bedarf an.
- Verwaltungsaufwand minimieren möchten. Keine verpflichtende Sprint-Planung, keine täglichen Stand-ups, kein Sprint Review, obwohl Sie diese Zeremonien übernehmen können, wenn sie hilfreich sind.
- Kontinuierliche Verbesserung anstreben. Regelmässige Feedback-Schleifen, wöchentliche Flow-Reviews oder kurze Retrospektiven ermöglichen es, Richtlinien, Spaltendefinitionen oder WIP-Grenzen anzupassen, sobald Sie Ineffizienzen feststellen.
- Visuelle Transparenz bevorzugen. Ein dauerhaftes Kanban-Board zeigt klar, woran alle gerade arbeiten, was blockiert ist und was als Nächstes kommt, ohne das Board in jedem Zyklus neu aufzubauen.
In Entwicklungsteams, bei denen eine schnelle Reaktion wichtig ist, passt Kanban oft ideal. Es hilft Ihnen, Nachfrage und Kapazität auszubalancieren, Engpässe sichtbar zu machen und den Prozess Schritt für Schritt zu verbessern.
Kombination von Scrum und Kanban: Scrumban
Manchmal liegt die beste Lösung zwischen zwei Extremen. Scrumban verbindet den Rhythmus von Scrum mit dem Flow-Fokus von Kanban und bietet Struktur, ohne dabei an Flexibilität zu verlieren.
Warum Scrumban?
- Sie schätzen Sprints für Planung und Reviews, möchten aber den kontinuierlichen Arbeitsfluss von Kanban, um Unterbrechungen besser zu bewältigen.
- Ihr Team muss Work-in-Progress begrenzen, um Kontextwechsel zu vermeiden, soll aber weiterhin Velocity für Stakeholder berichten.
- Sie möchten regelmässige Retrospektiven durchführen, aber auch schnelle, spontane Anpassungen an WIP-Grenzen oder Board-Richtlinien ermöglichen.
So funktioniert Scrumban
Sprint-Planung in Light-Version
- Zu Beginn eines Sprints wählen Sie eine kleine Anzahl priorisierter Arbeitselemente aus, kein vollständiges Sprint-Backlog.
- Verwenden Sie dieses Meeting, um Ziele zu setzen, lassen Sie aber Raum für neue Karten, die ins Board aufgenommen werden, sobald Kapazität frei wird.
Kanban-Board mit WIP-Grenzen
- Behalten Sie ein dauerhaftes Kanban-Board mit Spalten bei, die Ihrem Workflow entsprechen.
- Wenden Sie WIP-Grenzen in kritischen Phasen wie „In Bearbeitung“ oder „Review“ an, um den Fokus zu erzwingen und Aufgaben abzuschliessen.
Tägliche Stand-ups
- Behalten Sie das kurze Check-in bei: Was haben Sie gestern gemacht? Was machen Sie heute? Gibt es Blockaden?
- Nutzen Sie das Board während des Stand-ups, um Engpässe und Fortschritt sichtbar zu machen.
Sprint-Reviews und Retrospektiven
- Führen Sie Sprint-Reviews durch, um abgeschlossene Arbeitsergebnisse zu präsentieren und Feedback einzuholen.
- Halten Sie Retrospektiven ab, um Prozessanpassungen zu identifizieren, sowohl auf Sprint-Ebene als auch für laufende Kanban-Richtlinien.
Flow-Metriken und Velocity
- Verfolgen Sie Zykluszeit und Durchlaufzeit, um Verzögerungen im Arbeitsfluss zu erkennen.
- Messen Sie optional Velocity für abgeschlossene Arbeitselemente, um Prognosen zu unterstützen, ohne sich zu überfordern.
Wann Scrumban einsetzen?
- Ihr Team fühlt sich mit Scrum wohl, braucht aber mehr Agilität für ungeplante Arbeitselemente.
- Sie sind aus starren Sprint-Grenzen herausgewachsen und möchten eine Haltung der kontinuierlichen Verbesserung in den Alltag integrieren.
- Sie müssen Vorhersehbarkeit (Fälligkeitsdaten, Sprint-Reviews) mit Anpassungsfähigkeit (WIP-Grenzen, dynamische Prioritäten) in Einklang bringen.
Scrumban kann als Übergangslösung dienen: Scrum-Teams können Kanban-Prinzipien schrittweise einführen, während Kanban-Teams Sprint-Rhythmen übernehmen, um Planung und Einbindung der Stakeholder zu verbessern. Durch die Kombination von Routinen und Flow-Kontrollen entsteht mit Scrumban ein hybrider Ansatz, der sich realen Anforderungen anpasst, ohne unnötigen Zeremonienaufwand.
Fazit
Scrum und Kanban bringen Ordnung in das Chaos der Produktentwicklung. Die Entscheidung zwischen Kanban oder Scrum ist keine Frage von richtig oder falsch, sondern von Passung. Die eine Methode bietet planbare Zyklen und klar definierte Rollen, die andere ein dynamisches Pull-basiertes Board und ein anpassungsfähiges Tempo. Wenn Sie sowohl Vorhersehbarkeit als auch Flexibilität benötigen, kombiniert Scrumban Planungs-Checkpoints mit bedarfsorientierter Aufgabenaufnahme.
WEDO bringt diese Rahmenwerke von der Theorie in die Praxis. Mit integrierten Kanban-Boards, Tools zur Sprint-Planung, individuell anpassbaren Workflows und Echtzeit-Analysen – alles sicher in der Schweiz gehostet – vereint WEDO jede Aufgabe, jede Sitzung und jede Frist an einem Ort. Ob Sie ein Sprint-Review durchführen, Ihren Arbeitsfluss optimieren oder die Zykluszeit verfolgen, WEDO passt sich Ihrem Prozess an, damit sich Ihr Team auf das Wesentliche konzentrieren kann: Dinge erledigen.
Bereit für einen reibungsloseren Workflow? Testen Sie WEDO noch heute.
