Scrum hat fünf Events: den Sprint, Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospective. Der Sprint ist ein Container mit fester Länge von höchstens einem Monat, der die anderen vier enthält, und jedes davon hat eine maximale Timebox: 8 Stunden für Sprint Planning, 15 Minuten für das Daily Scrum, 4 Stunden für das Sprint Review und 3 Stunden für die Sprint Retrospective, bezogen auf einen Sprint von einem Monat. Kürzere Sprints haben meist kürzere Events.
Das ist die Kurzantwort. Der Rest dieses Artikels erklärt den Zweck jedes Events, wer teilnimmt, was eine Timebox wirklich bedeutet und welche Fragen zu den Events bei den Prüfungen PSM I, PSPO I und CSM viele Leute aufs Glatteis führen. Alles hier folgt dem Scrum Guide 2020.
Scrum Events und Timeboxes auf einen Blick
Eine Timebox ist ein Maximum, kein Ziel. Die Werte im Scrum Guide gelten für einen Sprint von einem Monat.
| Event | Maximale Timebox (Sprint von einem Monat) | Wer nimmt teil | Wichtigstes Ergebnis |
|---|---|---|---|
| Sprint | Feste Länge, höchstens ein Monat | Das gesamte Scrum Team | Ein oder mehrere fertige Increments auf das Product Goal hin |
| Sprint Planning | 8 Stunden | Das gesamte Scrum Team (weitere Personen können als Berater eingeladen werden) | Sprint Goal und Sprint Backlog |
| Daily Scrum | 15 Minuten, jeden Tag | Die Developers | Ein angepasster Plan für den nächsten Arbeitstag |
| Sprint Review | 4 Stunden | Das Scrum Team und wichtige Stakeholder | Gemeinsames Verständnis des Fortschritts und ein angepasstes Product Backlog |
| Sprint Retrospective | 3 Stunden | Das Scrum Team | Verbesserungen bei Qualität und Wirksamkeit |
Der Sprint: das Container-Event
Der Sprint ist ein eigenes Event, und er ist das, was man beim Zählen vergisst. Er hat eine feste Länge von höchstens einem Monat und enthält Sprint Planning, die Daily Scrums, das Sprint Review und die Sprint Retrospective. Die gesamte Arbeit, die nötig ist, um das Product Goal zu erreichen, findet innerhalb von Sprints statt. Ein neuer Sprint beginnt unmittelbar nach dem Ende des vorherigen.
Der Sprint hat eine feste Länge und ist kein Maximum, das man nach Belieben verkürzen könnte. Ein Sprint endet nur dann vorzeitig, wenn er abgebrochen wird, und nur der Product Owner kann einen Sprint abbrechen, und zwar wenn das Sprint Goal obsolet wird. Der Scrum Master, die Developers, Stakeholder oder das Management können ihn nicht abbrechen, auch wenn sie das Thema natürlich beim Product Owner ansprechen können.
Sprint Planning (max. 8 Stunden)
Sprint Planning startet den Sprint. Das gesamte Scrum Team erarbeitet den Plan gemeinsam und kann andere Personen einladen, die beraten. Es behandelt drei Themen:
- Warum ist dieser Sprint wertvoll? Das Scrum Team formuliert das Sprint Goal, das einzelne Ziel für den Sprint.
- Was kann in diesem Sprint fertig (Done) werden? Die Developers wählen im Gespräch mit dem Product Owner Einträge aus dem Product Backlog aus.
- Wie wird die ausgewählte Arbeit erledigt? Die Developers planen die Arbeit, die nötig ist, um die ausgewählten Einträge in ein Increment zu verwandeln, das die Definition of Done erfüllt.
Das Sprint Goal, die ausgewählten Product-Backlog-Einträge und der Plan zu ihrer Umsetzung bilden zusammen das Sprint Backlog, das den Developers gehört.
Daily Scrum (15 Minuten)
Das Daily Scrum ist ein 15-minütiges Event für die Developers. Sein Zweck ist es, den Fortschritt in Richtung Sprint Goal zu inspizieren und das Sprint Backlog bei Bedarf anzupassen. Es findet an jedem Arbeitstag des Sprints zur selben Zeit am selben Ort statt, um die Komplexität zu verringern.
Die Developers können jede beliebige Struktur oder Technik verwenden, solange der Fokus auf dem Fortschritt in Richtung Sprint Goal und einem Plan für den nächsten Tag liegt. Die bekannten „drei Fragen“ sind eine Möglichkeit, keine Regel. Wenn der Product Owner oder der Scrum Master aktiv an Einträgen im Sprint Backlog arbeiten, nehmen sie als Developers teil.
Das Daily Scrum ist kein Statusbericht an den Scrum Master oder eine Führungskraft, und es ist nicht die einzige Gelegenheit, bei der die Developers ihren Plan anpassen können. Sie können sich jederzeit im Laufe des Tages abstimmen und neu planen.
Sprint Review (max. 4 Stunden)
Das Sprint Review inspiziert das Ergebnis des Sprints und legt künftige Anpassungen fest. Das Scrum Team präsentiert die Ergebnisse seiner Arbeit den wichtigen Stakeholdern, und gemeinsam besprechen sie den Fortschritt in Richtung Product Goal und was sich in ihrem Umfeld verändert hat. Das Product Backlog kann angepasst werden, um neue Chancen abzubilden.
Der Scrum Guide beschreibt es als Arbeitssitzung und sagt, das Scrum Team solle es nicht auf eine Präsentation beschränken. Zwei Folgen sind für die Prüfung wichtig:
- Es ist kein Freigabe-Gate für Releases. Ein Increment kann den Stakeholdern ausgeliefert werden, sobald es die Definition of Done erfüllt, auch schon vor dem Sprint Review. Niemand muss auf das Review warten, um ein Release freizugeben.
- Es wird nur fertige Arbeit gezeigt. Arbeit, die die Definition of Done nicht erfüllt, ist kein Teil eines Increments, kann im Sprint Review nicht präsentiert werden und geht zurück ins Product Backlog.
Sprint Retrospective (max. 3 Stunden)
Die Sprint Retrospective schließt den Sprint ab. Ihr Zweck ist es, Wege zu planen, um Qualität und Wirksamkeit zu steigern. Das Scrum Team inspiziert, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Tools und seine Definition of Done gelaufen ist, und ermittelt dann die hilfreichsten Änderungen. Die wirkungsvollsten Verbesserungen werden so schnell wie möglich angegangen und können sogar ins Sprint Backlog des nächsten Sprints aufgenommen werden.
Was, wenn ein Event früher endet oder zu kurz ausfällt?
Weil eine Timebox ein Maximum ist, kann ein Event enden, sobald sein Zweck erreicht ist. Ein Sprint Planning, das in drei Stunden ein klares Sprint Goal und einen tragfähigen Plan liefert, ist in Ordnung. Ein 15-minütiges Daily Scrum, das nach acht Minuten fertig ist, ist ebenfalls in Ordnung.
Der umgekehrte Fall ist wichtiger: Ein Event sollte seine Timebox nicht überschreiten. Wenn das Sprint Planning ständig überzieht, ist das ein Anlass zur Inspektion. Vielleicht sind die Product-Backlog-Einträge nicht genug verfeinert, oder das Meeting driftet von seinen drei Themen ab. Der Scrum Master hilft dem Team sicherzustellen, dass die Events stattfinden, positiv und produktiv sind und innerhalb der Timebox bleiben.
Bei Sprints, die kürzer als ein Monat sind, sind die Events laut Guide in der Regel kürzer. Eine Formel nennt er nicht, erwarte also keine Prüfungsfrage, die dich einen genauen Wert für einen Sprint von zwei Wochen berechnen lässt. Bekannt sind die Maximalwerte für einen Sprint von einem Monat.
Warum Product Backlog refinement kein Event ist
Refinement bedeutet, Product-Backlog-Einträge in kleinere, präzisere Einträge aufzuteilen und weiter zu definieren, indem Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Der Scrum Guide 2020 behandelt es als fortlaufende Aktivität, nicht als Event, es hat also keine Timebox und kein festes Meeting.
Ältere Versionen des Guides schlugen vor, dass Refinement in der Regel nicht mehr als 10 % der Kapazität der Developers beanspruchen sollte. Diese Zahl wurde 2020 gestrichen, und der aktuelle Guide nennt keinen Prozentsatz. Wenn eine Antwortoption „10% of capacity“ als Regel nennt, ist sie veraltet.
Prüfungsfragen zu den Scrum Events, die viele falsch beantworten
- „How many Scrum events are there?“ Fünf. Der Sprint zählt als Event und ist der Container für die anderen vier. Refinement gehört nicht dazu.
- „Who must attend the Daily Scrum?“ Es ist für die Developers. Der Scrum Master muss es weder leiten noch anwesend sein, und der Product Owner nimmt nur als Developer teil, wenn er an Sprint-Backlog-Einträgen arbeitet.
- „Is the Sprint Review where the Product Owner approves the release?“ Nein. Es ist eine Arbeitssitzung, um das Increment zu inspizieren und das Product Backlog anzupassen. Releases können jederzeit stattfinden, sobald ein Increment fertig (Done) ist.
- „Can the Scrum Master cancel the Sprint?“ Nein. Nur der Product Owner kann das, wenn das Sprint Goal obsolet wird.
- „Can you extend a Sprint to finish the work?“ Nein. Der Sprint hat eine feste Länge. Unfertige Einträge gehen zurück ins Product Backlog.
- „What is the timebox for a two-week Sprint Planning?“ Der Guide legt nur das Maximum für einen Sprint von einem Monat fest (8 Stunden) und sagt, dass kürzere Sprints in der Regel kürzere Events haben.
Wenn du prüfen willst, wie gut diese Regeln sitzen, probiere die kostenlose PSM-Probeprüfung auf Scrumdemy: 20 Fragen in 20 Minuten, mit einer Bestehensgrenze von 80 %. Für intensiveres Üben enthält das Scrum-Master-Zertifizierungstraining vier Prüfungen mit Zeitlimit und 316 Fragen.
FAQ
Was sind die 5 Scrum Events?
Der Sprint, Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospective. Der Sprint enthält die anderen vier.
Wie lauten die Scrum Timeboxes für einen Sprint von einem Monat?
Sprint Planning hat ein Maximum von 8 Stunden, das Daily Scrum 15 Minuten, das Sprint Review 4 Stunden und die Sprint Retrospective 3 Stunden. Der Sprint selbst dauert höchstens einen Monat.
Ist Product Backlog refinement ein Scrum Event?
Nein. Im Scrum Guide 2020 ist Refinement eine fortlaufende Aktivität ohne Timebox, und die alte Richtlinie von 10 % der Kapazität wurde gestrichen.
Wer kann einen Sprint abbrechen?
Nur der Product Owner, und nur wenn das Sprint Goal obsolet wird.