Auf einen Blick
Im Scrum-Framework existieren 5 Ereignisse, die alle mit einer maximalen Dauer (Timebox) versehen sind: Sprint, Sprint-Planung, Daily Scrum, Sprint Review und Sprint-Retrospektive. Dieser Artikel gibt einen Überblick über Zweck, wichtigste Inhalte und Dauer der Events.
Was genau hat es mit den Scrum-Events auf sich? Wofür sind sie gut und wie laufen sie ab? In diesem Artikel schauen wir näher hin.
Gleich vorab: Die Begriffe „Event“ oder „Ereignis“ klingen im ersten Moment etwas sperrig. Doch keine Angst: Bis auf den übergeordneten Sprint sind sie nichts anderes als Meetings bzw. Besprechungen, die fest im Prozess eingeplant sind.
Die Scrum-Events im Überblick
Im Scrum-Framework existieren laut Scrum Guide 5 Events (Ereignisse), die alle mit einer maximalen Dauer (Timebox) versehen sind:
- Der Sprint als Container für die anderen Ereignisse
- Sprint-Planung zum Beginn eines Sprints
- Daily Scrum als tägliches Meeting während der Sprint-Ausführung
- Sprint Review zur Präsentation und Analyse des Sprint-Ergebnisses
- Sprint-Retrospektive zur Analyse des Prozesses und der Zusammenarbeit
Die folgende Tabelle zeigt eine Übersicht über alle Events mit ihren Zeitpunkten, der maximalen Dauer, den Teilnehmern und dem Inhalt in Kurzform:
Warum gibt es so viele definierte Ereignisse im Scrum-Framework? Ganz einfach: Jedes Meeting dient dazu, die Transparenz in einem Scrum-Projekt zu erhöhen und allen Beteiligten die Möglichkeit zu geben, sich über den aktuellen Projektfortschritt auszutauschen.
Ein wichtiges Grundprinzip im Scrum ist das „Überprüfen und Anpassen“ (Inspect & Adapt). Bis auf den Sprint selbst bieten alle Ereignisse die Möglichkeit, die aktuelle Arbeit kritisch zu begutachten und wenn nötig den Kurs zu korrigieren. Indem regelmäßig in kurzen Abständen definierte Meetings stattfinden, ist regelmäßiges Feedback garantiert und dieses schützt wiederum davor, das Produkt nicht am Markt und den Zielstellungen vorbei zu entwickeln.
Sprint
Der Sprint ist das Herzstück von Scrum: eine Timebox von maximal einem Monat, innerhalb dessen ein potenziell auslieferbares Produktinkrement erstellt wird, das der Definition von Fertig (Done) entspricht. Sprints können als eine Art Mini-Projekt angesehen werden: Es existiert eine klare Zielvorgabe, auf die das gesamte Team hinarbeitet.
Die Begrenzung auf einen Monat hat folgende Vorteile:
- Der Zeitraum ist kurz genug um Risiken und die Komplexität in einem überschaubaren Rahmen zu halten.
- Durch regelmäßiges Feedback in kurzen Abständen können Probleme frühzeitig erkannt und die eingeschlagene Richtung angepasst werden.
- Kurze Sprints lassen sich leichter mit anderen Business-Ereignissen synchronisieren.
- Längere Sprints würden höhere Dokumentationsaufwände verursachen.
- Anforderungen könnten sich bei längeren Zeiträumen schon während des Sprints erheblich ändern.
Daily Scrum
Der Name ist Programm: Dieses Scrum-Event findet am häufigsten statt. Im Daily Scrum trifft sich das Entwicklungsteam täglich, um den aktuellen Stand zu kommunizieren und nächste Schritte abzuleiten.
Der Scrum-Guide gibt keinen festen Ablauf für das Daily Scrum vor. Struktur und Ablauf können allein vom Entwicklungsteam bestimmt werden, solange es es dem Hinarbeiten auf das gemeinsame Sprint-Ziel dient.
In der Praxis hat sich dennoch ein Ablauf bewährt. Jedes Team beantwortet die folgenden drei Fragen:
- Was habe ich gestern getan, damit das Team das Sprint-Ziel erreicht?
- Was werde ich heute tun, damit das Team das Sprint-Ziel erreicht?
- Welche Probleme und Hindernisse sehe ich für meine Arbeit?
Im Unterschied zu traditionellen Meetings gibt es keinen Leiter, der dem Meeting vorsitzt und Fragen an alle Beteiligten stellt. Stattdessen organisiert sich auch hier das Team selbst und wirft beispielsweise demjenigen einen Ball zu, der als nächstes das Wort hat.
Das Daily Scrum-Meeting wird oft auch als Daily Standup bezeichnet, da es üblicherweise im Stehen abgehalten wird. Laut Scrum-Guide dauert es 15 Minuten, unabhängig von Sprintlänge oder Teamgröße. Findet das Daily Scrum täglich zur gleichen Zeit am gleichen Ort statt, etabliert sich das Meeting schnell zu einer starken Gewohnheit.
Was passiert, wenn Probleme angesprochen werden? Auch hierfür gibt es Regeln: Sind es interne Probleme, ist das Entwicklungsteam selbst für die Lösung verantwortlich. Behindern externe Hindernisse die Arbeit, werden sie an den Scrum Master weitergeleitet, der die Probleme soweit möglich ausräumt.
Sprint Planning
In der Sprint-Planung werden die Elemente des Product Backlogs ausgewählt, die im Sprint bearbeitet werden sollen. Diese werden näher beleuchtet und es wird definiert, wie sie praktisch umgesetzt und in welche Teilaufgaben sie zerlegt werden. Das so erarbeitete Sprint Backlog enthält folgende Inhalte:
- Ausgewählte Product-Backlog-Elemente
- Den Umsetzungsplan zur Lieferung der ausgewählten Elemente
- Mindestens ein hochpriorisiertes Element zur Verbesserung des Prozesses aus der Sprint-Retrospektive
Während der Sprint-Planung werden drei wichtige Fragen beantwortet:
- Was ist das Sprint-Ziel? Das Sprint-Ziel wird vom Team erarbeitet und dient als Leitlinie für den aktuellen Sprint. Der Product Owner spielt hier eine große Rolle: Er stellt vor, welche Vorstellung er vom nächsten Produktinkrement hat und welche Elemente aus dem Product Backlog diese widerspiegeln.
- Was kann während dieses Sprints erledigt werden? Es werden die Elemente aus dem Product Backlog ausgewählt, die in diesem Sprint bearbeitet werden sollen. Welche Elemente das sind, entscheidet allein das Entwicklungsteam.
- Wie wird die ausgewählte Arbeit erledigt? Das Entwicklungsteam entscheidet, wie es das Produktinkrement erstellen möchte, damit es den Zustand von „Fertig“ (Done) erreicht. Als Hilfsmittel dient das Sprint Backlog: eine Auswahl der Elemente aus dem Product Backlog ergänzt durch den Umsetzungsplan des Entwicklungsteams.
Nach Abschluss der Sprint-Planung haben alle Beteiligten ein klares Bild vom Sprint-Ziel. Es wurden Elemente des Product Backlogs ausgewählt, in ein Sprint Backlog überführt und in Einzelaufgaben untergliedert. Die Sprint-Planung dauert maximal 8 Stunden für einen einmonatigen Sprint, bei kürzeren Sprints entsprechend kürzer.
Warum ist die Sprint-Planung so wichtig? Weil alle Beteiligten ein gemeinsames Verständnis darüber erhalten, was auf welche Weise erreicht werden soll.
Sprint Review
In welchem Scrum-Event werden die Ergebnisse des Sprints den Stakeholdern vorgestellt und über nächste Schritte gesprochen? Genau: im Sprint Review. Folgende Fragen werden beantwortet:
- Sind die Stakeholder mit den implementierten Funktionen zufrieden?
- Haben sich Marktbedingungen oder sonstige Anforderungen geändert, die eine Anpassung nötig machen?
- Was ist als nächstes geplant?
Die einzelnen Rollen haben im Sprint-Review folgende Aufgaben:
- Das Entwicklungsteam präsentiert das Produktinkrement und beantwortet Fragen dazu. Außerdem diskutiert es über Verlauf, Ergebnisse und Probleme während des vergangenen Sprints.
- Der Product Owner beschreibt die Elemente des Product Backlogs, die Fertig (Done) sind – und welche nicht. Weiterhin wird der aktuelle Stand des Product Backlogs vorgestellt und mögliche Liefertermine vorgestellt.
- Alle Teilnehmer arbeiten gemeinsam an der Definition der nächsten Schritte, die in die Sprint-Planung des nächsten Sprints eingehen. Märkte, das Projektumfeld, Zeitpläne und mögliche Kriterien für kommende Produktreleases werden ebenfalls besprochen.
Am Sprint Review nehmen das gesamte Scrum-Team und vom Product Owner eingeladene Stakeholder teil. Das Meeting dauert 4 Stunden für einen einmonatigen Sprint und ist bei kürzeren Sprints entsprechend kürzer.
Sprint-Retrospektive
Gemäß des Scrum-Ansatzes des „Überprüfens und Anpassens“ (Inspect & Adapt) erhält das Scrum-Team am Ende eines jeden Sprints die Möglichkeit, die eigenen Prozesse zu prüfen und zu verbessern – dieses Scrum-Event ist genau dafür gemacht.
Die Sprint-Retrospektive findet nach dem Sprint Review und vor der nächsten Sprint-Planung statt. Das Meeting sollte maximal 3 Stunden für einen einmonatigen Sprint dauern, bei kürzeren Sprints entsprechend kürzer.
Die Grundidee: Die Arbeit(sweise) des Scrum-Teams wird untersucht und Verbesserungen für den nächsten Sprint abgeleitet. Statt des eigentlichen Produkts stehen Prozesse, Zusammenarbeit und Praktiken im Zentrum.
Am Meeting nimmt das gesamte Scrum-Team teil. Der Scrum Master fungiert hierbei als Wächter über den Scrum-Prozess als „Peer Team Member“, leitet das Meeting jedoch nicht. Zwar gibt er Hilfestellungen, schreibt dem Team jedoch nicht vor, wie es die Prozesse anpassen soll.
Potenzielle Verbesserungen werden definiert und überlegt, wie diese umgesetzt werden können. Folgende Fragen können bei der Erarbeitung helfen:
- Was hat gut funktioniert und soll weitergeführt werden?
- Was hat nicht gut funktioniert und sollte vermieden werden?
- Was wollen wir Neues ausprobieren?
In der Sprint-Retrospektive kann zudem die „Definition of Done“ angepasst werden, um die Produktqualität zu erhöhen. Um realen Nutzen aus der Sprint-Retrospektive zu ziehen, wird mindestens eine hochpriorisierte Verbesserung ins Sprint Backlog des nächsten Sprints aufgenommen.
Fazit
Die Scrum-Events gehören zu den wichtigsten Elementen des Scrum-Frameworks. Die fest definierten Meetings helfen dem Team dabei, regelmäßig das Prinzip „Überprüfen und Anpassen“ (Inspect & Adapt) praktisch in die Tat umzusetzen.