Scrum mit Kanban [Kanban]

10 Übungsfragen mit Lösung und Erklärung.

☝️ SingleWas ändert sich an den Scrum-Events, wenn ein Team Kanban-Praktiken einsetzt?
❌Das Daily Scrum entfällt, weil das Board den Stand zeigt
✅Nichts an ihrer Existenz – sie bleiben vollständig erhalten, nutzen aber zusätzlich Flow-Metriken als Grundlage für Inspektion und Adaption
❌Der Sprint entfällt zugunsten eines kontinuierlichen Flusses
❌Sprint Review und Retrospektive werden zusammengelegt
Wer Sprint oder Events streicht, macht kein Scrum mehr. Der Kanban Guide for Scrum Teams setzt die Gültigkeit des Scrum Guide ausdrücklich voraus.
☝️ SingleWie verändert ein flussbasiertes Vorgehen das Sprint Planning?
❌Es wird ausschließlich das Sprint-Ziel festgelegt, ohne Auswahl von Einträgen
❌Der Product Owner wählt die Einträge allein aus
✅Statt über Velocity wird über Durchsatz und Durchlaufzeit prognostiziert; die Auswahl kann kleiner ausfallen und im Sprint ergänzt werden
❌Das Sprint Planning entfällt vollständig
Das Sprint-Ziel bleibt in jedem Fall verbindlich. Verändert wird nur die Grundlage der Mengenabschätzung – historische Durchsatzdaten statt Punktesummen.
☝️ SingleWie verändert sich das Daily Scrum in einem flussorientierten Team?
✅Es orientiert sich am Board und am Alter der laufenden Einheiten: zuerst die Arbeit, die ins Stocken geraten ist, statt reihum Personenberichte
❌Es wird vom Scrum Master moderiert statt von den Developers geführt
❌Es entfällt, weil das Board bereits Transparenz schafft
❌Es wird auf fünf Minuten verkürzt
Das Alter der laufenden Einheiten liefert eine bessere Tagesordnung als jede Personenrunde: Es zeigt, wo der Fluss hakt – und genau darum geht es im Daily.
✌️ MultiWas gilt für den Scrum-Rahmen, wenn ein Team Kanban-Praktiken übernimmt? (Mehrere richtig)
❌Ein Team muss sich zwischen Scrum und Kanban entscheiden.
✅Beide beruhen auf Transparenz sowie regelmäßiger Inspektion und Anpassung.
✅Kanban schreibt keine Rollen, Events oder Artefakte vor.
✅Kanban-Praktiken lassen sich innerhalb des Scrum-Rahmens einsetzen, ohne ihn zu verletzen.
Kanban ist eine Methode zur Verbesserung bestehender Prozesse und beginnt ausdrücklich dort, wo man steht – deshalb ist es mit Scrum kombinierbar statt konkurrierend.
☝️ SingleWas bedeutet "aktives Management der laufenden Arbeitseinheiten"?
❌Der Product Owner priorisiert die laufenden Einheiten täglich neu
❌Jede Einheit erhält eine feste Bearbeitungszeit
❌Der Scrum Master weist den Developers täglich Arbeitseinheiten zu
✅Blockaden und stockende Einheiten werden laufend erkannt und aufgelöst, statt nur den Fortschritt zu beobachten
Der Unterschied zum bloßen Beobachten ist das Eingreifen: Blockaden sichtbar machen, Ursachen auflösen, unnötige Warteschlangen abbauen und alte Einheiten bevorzugt abschließen.
✍️ OffenEin Team möchte Kanban einführen und dafür die Sprints abschaffen. Beziehen Sie Stellung.
Musterantwort: Der Wunsch beruht meist auf einem Missverständnis: Kanban wird als Alternative zu Scrum verstanden, obwohl es eine Methode zur Verbesserung eines bestehenden Prozesses ist und ausdrücklich dort ansetzt, wo man steht. Wer Sprint, Events und Artefakte streicht, macht kein Scrum mehr, sondern arbeitet in einem reinen Flusssystem – das ist legitim, aber eine andere Entscheidung als die, Kanban-Praktiken einzusetzen. Zunächst würde ich klären, welches Problem eigentlich gelöst werden soll. Häufig steckt dahinter, dass der Sprint als künstliche Grenze empfunden wird, dass ständig Arbeit unfertig überhängt oder dass Störungsarbeit die Planung entwertet. Für all diese Probleme gibt es Antworten innerhalb von Scrum: kleinere Einträge, WIP-Limits, eine strengere Definition of Done oder eingeplante Kapazität für Störungen. Der Kanban Guide for Scrum Teams beschreibt genau diese Kombination, und sie bringt die erhofften Vorteile, ohne den Rahmen aufzugeben. Was der Sprint dabei liefert und ein reines Flusssystem nicht bietet, ist der regelmäßige Takt für Inspektion und Adaption sowie das Sprint-Ziel als gemeinsamer Fokus. Gerade Teams, die sich verzetteln, verlieren ohne diesen Takt eher an Ausrichtung. Mein Vorschlag wäre daher, zunächst Visualisierung, WIP-Limits und Flow-Metriken innerhalb der bestehenden Sprints einzuführen und nach einigen Sprints anhand der Daten erneut zu bewerten, ob der Sprint tatsächlich das Problem war.
☝️ SingleWie wird die Sprint Retrospective in einem flussorientierten Team genutzt?
❌Sie wird durch ein Flow-Review ersetzt
❌Sie entfällt, weil die Metriken bereits kontinuierlich gemessen werden
✅Flow-Metriken dienen als Datengrundlage, und die Definition of Workflow selbst wird überprüft und angepasst
❌Sie beschränkt sich auf die Überprüfung der WIP-Limits
Die vierte Kanban-Praktik lautet ausdrücklich: Definition of Workflow inspizieren und anpassen. Die Retrospektive ist dafür der vorgesehene Ort.
☝️ SingleWie wird das Sprint Review durch Flow-Daten bereichert?
✅Durchsatz und Durchlaufzeiten erlauben es, mit Stakeholdern über realistische Lieferfähigkeit und Prognosen mit Wahrscheinlichkeiten zu sprechen
❌Das Review wird durch eine Metrikpräsentation ersetzt
❌Die Stakeholder legen anhand der Daten die WIP-Limits fest
❌Das Increment wird nicht mehr gezeigt
Der Gegenstand des Reviews bleibt das Increment. Die Daten liefern nur die belastbare Antwort auf die Frage "wann kommt was", die dort ohnehin gestellt wird.
✌️ MultiWelche Aussagen zur Einführung von Flow-Praktiken in einem Scrum Team treffen zu? (Mehrere richtig)
✅Die Definition of Workflow wird vom Team selbst erarbeitet.
❌Der bestehende Prozess wird vor der Einführung vollständig neu entworfen.
✅Man beginnt mit dem bestehenden Prozess und macht ihn zunächst nur sichtbar.
✅WIP-Limits werden schrittweise eingeführt und angepasst.
Kanban ist eine Verbesserungsmethode, kein Neuentwurf. Der ganze Ansatz beruht darauf, evolutionär vorzugehen und damit den Widerstand zu vermeiden, den ein Bruch erzeugt.
☝️ SingleWelche Aussage über das Verhältnis von Scrum und Kanban trifft zu?
❌Scrum und Kanban schließen sich aus, da das eine getaktet und das andere flussbasiert arbeitet
❌Kanban ersetzt das Sprint Planning durch kontinuierliches Ziehen
❌Bei Einsatz von Kanban entfällt das Sprint-Ziel
✅Kanban-Praktiken ergänzen Scrum, ohne eines seiner Elemente zu ersetzen; Sprint, Events und Verantwortlichkeiten bleiben unverändert
Professional Scrum with Kanban fügt Flusspraktiken hinzu: Visualisierung, WIP-Limits, aktives Management des Flusses und Flusskennzahlen. Der Rahmen bleibt Scrum. Wer Sprint-Ziel oder Events streicht, macht kein Scrum mit Kanban, sondern etwas anderes.
← Alle ThemenIm Quiz üben