6 Scrum-Events im Überblick: Wofür sie wirklich da sind
Die 6 Scrum-Events: 1. Sprint (umschließend, 1–4 Wochen). 2. Sprint Planning (max. 8 h, „Was und Wie?“). 3. Daily Scrum (15 min, Synchronisation). 4. Sprint Review (max. 4 h, Increment + Feedback). 5. Sprint Retrospektive (max. 3 h, Verbesserung der Zusammenarbeit). Plus das Backlog Refinement, kein offizielles Event, aber praktische Pflicht (≤10 % der Sprint-Kapazität). Jedes Event hat einen klaren Zweck. Wer das nicht kennt, macht Theater.
Scrum-Events sind keine Meetings, sondern Synchronisations- und Inspektionspunkte. Jedes hat ein definiertes Ergebnis. Ohne dieses Ergebnis ist das Event wertlos.
Hier die 6 in der natürlichen Reihenfolge eines Sprints, mit Timebox, Teilnehmenden und dem Fehler, den die meisten Teams machen.
Der Sprint (umschließendes Event)
Dauer: 1–4 Wochen, konsistent. Zweck: Container für alle anderen Events und die eigentliche Arbeit. Ergebnis: ein potenziell auslieferbares Increment. Häufiger Fehler: Sprint-Länge verändern, weil „diese Aufgabe einfach länger dauert“. Konstante Länge schafft Rhythmus und Plan-barkeit.
Sprint Planning
Timebox: max. 8 h für 4-Wochen-Sprint, anteilig kürzer. Drei Fragen: Warum ist dieser Sprint wertvoll (Sprint-Ziel)? Was kann erreicht werden? Wie wird die Arbeit erledigt? Ergebnis: Sprint-Ziel + Sprint-Backlog. Fehler: Planning ohne klares Sprint-Ziel, das Team sammelt Items, ohne Fokus.
Daily Scrum
Timebox: 15 min, täglich, gleiche Zeit. Zweck: Fortschritt zum Sprint-Ziel inspizieren, Hindernisse identifizieren, nächste 24 h synchronisieren. Nur Entwickler. Ergebnis: Plan für den heutigen Tag. Fehler: Status an den Scrum Master melden, statt sich gegenseitig zu synchronisieren.
Sprint Review
Timebox: max. 4 h für 4-Wochen-Sprint. Zweck: Increment den Stakeholdern zeigen, Feedback einholen, Backlog ggf. anpassen. Ergebnis: aktualisiertes Backlog mit Stakeholder-Input. Fehler: Review als Demo-Theater verstehen, eine Show ohne echtes Stakeholder-Feedback ist verschwendete Zeit.
Sprint Retrospektive
Timebox: max. 3 h für 4-Wochen-Sprint. Zweck: Wie arbeiten wir zusammen, und wie können wir besser werden? Ergebnis: 1–2 konkrete Verbesserungen für den nächsten Sprint. Fehler: Retros ohne Action Item oder mit zu vielen Action Items, von denen keines umgesetzt wird.
Backlog Refinement (kein offizielles Event, aber Pflicht)
Empfohlen: max. 10 % der Sprint-Kapazität, 1–2x pro Sprint. Zweck: Backlog-Items klären, schätzen, splitten, bis zur Planning-Reife (INVEST-Kriterien). Ergebnis: 1–2 Sprints im Voraus refined. Fehler: Refinement weglassen und das Planning damit auf 4 h ausdehnen.
Fazit
Gemeinsamer Nenner: jedes Event braucht ein Ergebnis
Wenn ein Event endet, ohne dass das definierte Ergebnis vorliegt. Sprint-Ziel, Plan für 24 h, Stakeholder-Feedback, Action Item, refined Items, dann hat das Team Zeit verloren. Scrum Master sollte das aktiv prüfen, nicht moderieren um des Moderierens willen.
FAQs
:quality(85))
Fachkraft für agiles Projektmanagement (IHK)
Im Lehrgang verwandelst du dieses Wissen in einen konkreten Umsetzungsplan — mit Templates, Use Cases und IHK-Zertifikat.
Kostenlos testenthekey.academy ist eine deutsche Online-Lernplattform für IHK-zertifizierte berufliche Weiterbildung — 25 Lehrgänge zu KI, Führung, Resilienz, Marketing und HR. 100 % online, self-paced, mit IHK-Zertifikat.