Die fünf Scrum-Events richtig durchführen: Ablauf, Timeboxen, typische Fehler

Wozu dienen die Scrum-Events?

Die Events sind die Taktgeber von Scrum. Jedes ist eine formale Gelegenheit, Artefakte zu überprüfen und anzupassen, und sie sind so gestaltet, dass die nötige Transparenz entsteht ^[1]. Werden Events nicht wie vorgesehen durchgeführt, gehen Gelegenheiten zur Überprüfung und Anpassung verloren. Der Guide betont zudem, dass die Events Regelmässigkeit schaffen und den Bedarf an zusätzlichen Meetings reduzieren sollen. Idealerweise finden sie immer zur selben Zeit am selben Ort statt.

In der Praxis werden Events oft als lästige Pflicht empfunden. Das liegt selten an Scrum, sondern an der Durchführung: Events ohne klares Ergebnis, die zu lange dauern oder von einer Person dominiert werden. Die folgenden Abschnitte beschreiben für jedes Event Zweck, Ablauf, Ergebnis und typische Fehler.

Wie lange dauern die Events bei verschiedenen Sprintlängen?

Der Scrum Guide nennt Höchstdauern für einen Sprint von einem Monat; bei kürzeren Sprints sind die Events in der Regel kürzer ^[1]. Eine verbreitete Faustregel skaliert die Zeiten proportional zur Sprintlänge. Die folgende Tabelle zeigt die Werte des Guides und eine proportionale Orientierung für Sprints von zwei Wochen.

Timeboxen sind Höchstwerte, keine Pflichtdauern. Ein Event endet, sobald sein Zweck erreicht ist. Umgekehrt gilt: Wird die Timebox regelmässig voll ausgeschöpft oder überschritten, ist das ein Signal, dass die Vorbereitung fehlt, etwa ein nicht verfeinerter Backlog vor dem Planning.

Was gilt für den Sprint selbst?

Der Sprint ist das Herz von Scrum und ein Container fester Länge von höchstens einem Monat. Alle Arbeit, die zum Erreichen des Product Goals nötig ist, findet innerhalb von Sprints statt. Während des Sprints werden keine Änderungen vorgenommen, die das Sprint Goal gefährden, die Qualität sinkt nicht, der Backlog wird nach Bedarf verfeinert und der Umfang kann mit dem Product Owner geklärt und neu verhandelt werden ^[1]. Kürzere Sprints erzeugen mehr Lernzyklen und begrenzen das Risiko.

Wie läuft ein gutes Sprint Planning ab?

1. 1Warum: Der Product Owner schlägt vor, wie das Produkt im Sprint an Wert gewinnen kann; das Team formuliert gemeinsam ein Sprint Goal.
2. 2Was: Die Developers wählen im Gespräch mit dem Product Owner Einträge aus dem Backlog aus, gestützt auf ihre bisherige Leistung, Kapazität und Definition of Done.
3. 3Wie: Die Developers planen für jeden ausgewählten Eintrag die nötige Arbeit, oft durch Zerlegung in Aufgaben von einem Tag oder weniger.
4. 4Ergebnis: Sprint Goal, ausgewählte Einträge und Plan bilden zusammen den Sprint Backlog.

Das häufigste Problem im Planning ist ein unvorbereiteter Backlog. Wenn Einträge erst im Planning verstanden, zerlegt und geschätzt werden, wird die Timebox gesprengt. Deshalb gehört eine laufende Verfeinerung des Backlogs, das sogenannte Refinement, zur Arbeit im Sprint. Für die Kapazitätsplanung hilft der Sprintkapazität-Rechner; eine Vorlage bietet flenio.ch unter Sprint Planning.

Wie wird das Daily Scrum wirksam?

Das Daily Scrum ist ein 15-minütiges Event der Developers, um den Fortschritt zum Sprint Goal zu prüfen und den Sprint Backlog anzupassen. Es findet jeden Arbeitstag zur selben Zeit am selben Ort statt ^[1]. Die Developers wählen die Struktur selbst, solange das Treffen auf das Sprint Goal fokussiert und einen umsetzbaren Plan für den nächsten Tag ergibt. Die früher verbreiteten drei Fragen nach gestern, heute und Hindernissen sind eine mögliche, aber keine vorgeschriebene Form.

• Am Board statt reihum: Den Arbeitsfluss von rechts nach links durchgehen, also von fast fertigen zu neuen Aufgaben.
• Auf das Sprint Goal schauen: Sind wir auf Kurs, was gefährdet das Ziel?
• Hindernisse benennen, aber im Daily nicht lösen; Lösungen in einer Runde direkt danach mit den Betroffenen.
• Kein Statusbericht an Vorgesetzte: Das Daily gehört den Developers.
• Pünktlich beginnen und enden, auch wenn jemand fehlt.

Wie wird das Sprint Review zur Arbeitssitzung?

Im Sprint Review prüft das Scrum Team mit wichtigen Stakeholdern das Ergebnis des Sprints und legt künftige Anpassungen fest. Besprochen wird, was erreicht wurde, was sich im Umfeld verändert hat und was als Nächstes sinnvoll ist; der Product Backlog kann angepasst werden ^[1]. Der Guide betont ausdrücklich, dass das Review eine Arbeitssitzung ist und nicht auf eine Präsentation beschränkt werden sollte.

Wirksame Reviews zeigen funktionierende Ergebnisse statt Folien, laden die richtigen Stakeholder ein und enden mit konkreten Entscheiden für den Backlog. Ein Review, in dem das Team zwanzig Minuten präsentiert und die Stakeholder höflich nicken, verschenkt die wertvollste Feedbackgelegenheit des Sprints. Hilfreich ist eine kurze Struktur: Sprint Goal und Ergebnis, Vorführung am Produkt, Rückmeldungen sammeln, Veränderungen im Umfeld, nächste Prioritäten besprechen.

Was macht eine gute Retrospektive aus?

Die Sprint Retrospective beendet den Sprint. Ihr Zweck ist, Wege zur Steigerung von Qualität und Wirksamkeit zu planen. Das Team prüft, wie der Sprint in Bezug auf Personen, Zusammenarbeit, Prozesse, Werkzeuge und die Definition of Done verlief, und identifiziert die hilfreichsten Veränderungen; die wirksamsten werden so bald wie möglich umgesetzt, auch als Eintrag im nächsten Sprint Backlog ^[1]. Formate mit Anleitung beschreibt der Beitrag Retrospektive-Methoden.

Ist Backlog Refinement ein Event?

Nein. Refinement ist im Scrum Guide eine laufende Tätigkeit, kein Event. Einträge werden zerlegt, präzisiert und mit Beschreibung, Reihenfolge und Grösse versehen; die Developers, die die Arbeit erledigen, sind für die Grössenschätzung verantwortlich ^[1]. Viele Teams planen dafür trotzdem feste Termine, etwa einmal pro Woche eine Stunde. Das ist sinnvoll, solange klar ist, dass Refinement Arbeit am Backlog ist und kein zusätzliches Planning. Wie Einträge gut formuliert werden, zeigt der Beitrag User Stories schreiben.

Typische Fehler bei den Scrum-Events

Beispiel: Ein Sprint von zwei Wochen im Kalender

Ein Team, das in Sprints von zwei Wochen arbeitet, könnte seinen Kalender so gestalten: Montag der ersten Woche Sprint Planning am Vormittag, danach täglich um 9.15 Uhr das Daily Scrum. Mittwoch der ersten Woche eine Stunde Refinement für kommende Einträge. Freitag der zweiten Woche am Vormittag das Sprint Review mit Stakeholdern, am Nachmittag die Retrospektive. Am folgenden Montag beginnt der nächste Sprint. Die deutsche Fassung des Scrum Guides beschreibt dieselbe Logik der Events und eignet sich gut, um die Abläufe im Team gemeinsam zu lesen ^[3].

Feste Termine reduzieren Abstimmungsaufwand: Alle wissen, wann welches Event stattfindet, und Stakeholder können die Reviews langfristig einplanen. Verschiebungen sollten die Ausnahme sein. Fällt ein Feiertag in den Sprint, wird die Kapazität im Planning entsprechend reduziert, statt den Sprint zu verlängern.

Für Teams, die neu mit Scrum beginnen, lohnt sich zudem eine einfache Regel: In den ersten drei Sprints werden alle Events genau nach Guide durchgeführt, ohne Abkürzungen. Erst danach entscheidet das Team in der Retrospektive bewusst, was es an Struktur und Ablauf anpassen will. So wird vermieden, dass Elemente weggelassen werden, deren Nutzen sich erst nach einigen Zyklen zeigt, etwa ein gut vorbereitetes Review mit echten Stakeholdern.

Wer diese Disziplin einhält, erlebt die Events nach kurzer Zeit nicht mehr als Pflicht, sondern als Struktur, die Abstimmung erleichtert. Gute Events sparen Zeit, statt sie zu kosten.

Eine kurze Rückfrage am Ende jedes Events, ob es seinen Zweck erfüllt hat, hilft, die Qualität laufend zu verbessern.

Events im Verhältnis zu anderen Standards

Die Scrum-Events lassen sich mit klassischen Steuerungselementen verbinden. In hybriden Projekten ersetzt das Sprint Review oft einen Teil der Abnahmen, und die Ergebnisse fliessen in Statusberichte an den Auftraggeber ein. HERMES agil beschreibt, wie Releases und Sprints mit Steuerung und Freigaben zusammenspielen ^[2]. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis.