In Scrum spricht man von Ereignissen oder Aktivitäten statt von Meetings, um klarzustellen, dass es sich um Arbeit handelt. Alle Aktivitäten von Scrum haben feste Zeitfenster (Timeboxen), die nicht überschritten werden sollen.
Inhalt
Product Backlog Refinement
Das Product Backlog Refinement ist ein fortlaufender Prozess, bei dem der Product Owner und das Entwicklungsteam gemeinsam das Product Backlog weiterentwickeln. Hierzu gehören:
- Ordnen der Einträge
- Löschen von Einträgen, die nicht mehr wichtig sind
- Hinzufügen von neuen Einträgen
- Detaillieren von Einträgen
- Zusammenfassen von Einträgen
- Schätzen von Einträgen
- Planung von Releases
Für die Gestaltung des Produkts und des Team Backlogs können Stakeholder wertvolle Informationen liefern, indem sie dem Scrum Team erklären, wie sie sich eine Funktionalität im alltäglichen Gebrauch wünschen. Daher gibt es meistens auch regelmäßige Backlog Refinement Termine zusammen mit ausgewählten Stakeholdern.
Sprint Planning
Jeder Sprint beginnt mit dem Sprint Planning. In diesem Meeting werden die zu erledigenden Aufgaben für den kommenden Sprint ausgewählt. Grundlage bildet das priorisierte Product Backlog. Das Team bespricht mit dem Product Owner jeden Eintrag, kommt dabei zu einem gemeinsamen Verständnis der Aufgabe und darüber, was notwendig ist, um ihn im Einklang mit der aktuellen Definition of Done umzusetzen. Wie viele Aufgaben in den Sprint aufgenommen werden, entscheidet einzig das Umsetzungs-Team. In die Entscheidung, wie viel das Team sich vornimmt fließt ein, wer vom Team im kommenden Sprint verfügbar ist und wieviel das Team durchschnittlich in den vergangenen Sprints geschafft hat.
Am Ende vom Sprint Planning bekommt der Sprint ein Ziel. Diese Praktik hilft dem Team sich zu fokussieren und sich nicht mit Details aufzuhalten, die nicht so wichtig sind.
Das Sprint Planning endet mit dem Commitment, bei dem sich alle Teammitglieder gegenseitig dazu verpflichten, dass gesteckte Sprintziel auch zu erreichen.
Daily Scrum
Sobald der Sprint gestartet ist, nutzt das Entwicklungsteam das Daily Scrum Meeting (max. 15 Minuten), um sich zum Stand des Fortschritts auszutauschen und die Arbeit des Tages zu organisieren. Das Treffen findet täglich am gleichen Ort und zur gleichen Uhrzeit statt. Jedes Mitglied des Entwicklungsteams gibt dabei drei Informationen bekannt:
- Was habe ich seit dem letzten Daily Scrum erreicht?
- Was möchte ich bis zum nächsten Daily Scrum erreichen?
- Was bremst meinen Fortschritt?
Kurze Fragen sind erlaubt, es gibt aber keine weiterführende Diskussion einzelner Themen während des Daily Scrums. Sollte sich die Notwendigkeit ergeben, werden die Themen im Anschluss besprochen. Das Daily Scrum ist weder ein Report an das Management noch an den Product Owner oder den ScrumMaster. Es ist ein Kommunikations-Meeting innerhalb des Entwicklungsteams, das sicherstellt, dass alle störungsfrei arbeiten können. Während dieses Meetings äußern sich nur die Mitglieder Scrum Teams, einschliesslich des ScrumMasters und Product Owners. Andere Interessengruppen können teilnehmen und zuhören.
Das Daily Scrum ist ein wichtiges Element von Scrum, das zu Transparenz, Vertrauen und höherer Leistungsfähigkeit führt. Es stellt sicher, dass Probleme schnell erkannt werden, fördert die Selbstorganisation und das Selbstvertrauen des Teams.
Sprint Review
Das Sprint Review findet am Ende jeden Sprints statt und gibt den Anwesenden einen Überblick über das aktuelle Produktinkrement. In diesem Termin führt das Team den Stakeholdern die Ergebnisse des Sprints vor. Das Meeting ist informell – man sieht sich den aktuellen Stand an und arbeitet zusammen am weiteren Vorgehen. Dazu kann jeder etwas beitragen. Es kann sogar passieren, dass die Funktionalität alle Abnahmekriterien erfüllt und dennoch aus der Perspektive des Benutzers noch nicht vollends einsetzbar ist. Ziel des Sprint-Reviews ist, dass ein Dialog entsteht, bei dem den Anwesenden neue Funktionalitäten einfallen.
Es ist Aufgabe des Product Owners, die entwickelten Funktionalitäten zu prüfen. Anhand der im Sprint Planning festgelegten Bedingungen entscheidet er, ob sie abgenommen werden können oder nicht. Die Abnahme ist aber nicht primärer Gegenstand vom Sprint Review, bei dem es vorrangig um das Feedback der Stakeholder geht. Die Abnahme der Funktionalitäten des Produktinkrements erfolgt daher häufig bereits während des Sprints.
Die endgültige Entscheidung über die Zukunft des Produktes trifft der Product Owner indem er das Product Backlog entsprechend anpasst.
Sprint Retrospektive
Im Anschluss an das Sprint Review trifft sich das Scrum Team zur Sprint Retrospektive. Dieser Termin wird vom Scrum Master moderiert und dient dazu, den vergangenen Sprint hinsichtlich Prozess, Beziehungen zwischen den Team-Mitgliedern und der eingesetzten Werkzeuge zu beleuchten. Das Team identifiziert, was gut und was weniger gut gelaufen ist. Anschließend bespricht es Möglichkeiten zur Verbesserung und erarbeitet einen Plan zur Umsetzung. Das Scrum Team verbessert hierbei seinen eigenen Prozess innerhalb des Frameworks von Scrum.
Das Team soll seine Arbeitsweise offen und ehrlich besprechen können. Dazu müssen Kritik und manchmal auch unangenehme Wahrheiten offen geäußert werden können. Die Retrospektive soll daher in einem geschützten Rahmen ablaufen. Stakeholder dürfen nur auf Einladung teilnehmen.
Maßnahmen zur Verbesserung werden dokumentiert und geplant. Hierfür gibt es unterschiedliche Techniken. Einige Teams nutzen eine eigene Liste mit Hindernissen und Verbesserungsmaßnahmen (das Impediment Backlog), andere Teams nehmen Hindernisse und die entsprechenden Aktivitäten in das Sprint Backlog auf.
Die Retrospektive beendet den Sprint. Ab diesem Zeitpunkt wiederholt sich der Scrum-Zyklus.