Dieser Blog-Eintrag ist Teil einer Serie zur Detailbetrachtung von Scrum. Weitere Einträge finden Sie hier:
Innerhalb des Scrumprozesses werden folgende unterschiedliche Scrum Meetings definiert: Das Estimation Meetings, das Release Planning, das Sprint Planning, das Daily Scrum und das Scrum-Abschluss-Meeting.
Die Scrum Meetings im Detail
Das Estimation Meeting
Das Team trifft sich regelmäßig mit dem Product Owner, um neue Features zu schätzen. Dieses Estimation Meeting erfolgt immer dann, wenn neue Product Backlog Items in das Product Backlog überführt werden. Diese Schätzung sind keine Aufwandsschätzungen (Personen Tage Aufwand), sondern Schätzungen nach Story Points (Komplexitäts- und Vergleichwerte), die pro Product Backlog Item vorliegen.
Das Sprint Planning 1 – Release Planning
Das Release Planning ist ein Planungsmeeting, in dem die nächsten Releases in Zusammenarbeit zwischen Team und Product Owner geplant werden. Innerhalb dieses Meetings einigen sich das Team und der Product Owner auf das Selected Product Backlog welches im Rahmen des nächsten Sprints abgearbeitet wird. Sind schon Kennzahlen aus den vorherigen Sprints vorhanden (Velocity), so kann auch hier schon eine Prognose über mögliche weitere Sprints und deren Inhalt gemacht werde. Aufgrund des agilen Product Backlog Inhalts ist diese Planung aber als ein grober Vorgehensplan zu verstehen.
Das Sprint Planning 2 – Sprint / Iteration Planning
Sprint Planning ist ein Planungsmeeting an dem das Team den aktuellen Sprint detailliert plant. Hier werden die jeweils zu bearbeitenden User Stories in Arbeitspakete aufgeteilt und mit konkreten Zeitschätzungen versehen. Hierbei gilt, ein Arbeitspaket darf maximal einen Aufwand von einen Tag haben. Diese Zeitschätzung erfolgt, um so verlässlich wie möglich zu sein, vom jeweiligen Entwickler des Arbeitspaketes. Ein Wechsel der gesetzten Personen erfordert automatisch eine Neuschätzung der Aufgaben.
Das Daily Scrum
Im Daily Scrum Meeting erfolgt die eigentliche Scrum-Implementierung bzw. deren Team-Statusupdate. Hier werden die jeweiligen Aufgaben nach und nach abgearbeitet und innerhalb des fünfzehn-minütigen, täglichen StandUp Meetings besprochen. Um das Meeting so kurz wie möglich zu halten, dürfen nur drei Fragen beantwortet werden. Erstens: Was hast du gestern gemacht? Zweitens: Was wirst du heute machen? Drittens: Welche Probleme hindern dich bei deiner aktuellen Arbeit?
Das Daily Scrum Meeting findet jeden Tag zur gleichen Zeit und am gleichen Ort statt. Über die komplette Sprintdauer gesehen, werden die jeweiligen Tasks abgearbeitet und am Taskboard in der Reihenfolge aus dem Product Backlog und gruppiert pro Product Backlog Item visualisiert dargestellt.
Der Sprint Abschluss (Review und Retrospektive)
Am Ende jedes Sprints findet der Sprint Abschluss statt. Dieser teilt sich in zwei Bereiche: Einerseits die „Review“-Präsentation der Sprintergebnisse (Teilnehmer: Product Owner, Stakeholder, Scrum Master und Team) und andererseits die Sprint Retrospektive (Teilnehmer: Scrum Master und Team). Im Review wird der erarbeitete Stand präsentiert. Ohne lange Vorbereitung bzw. ohne Powerpoint-Folien. Demonstration direkt am System.
In der Retrospektive werden die lessons learned Punkte angesprochen und die Verbesserungspunkte im Team erarbeitet und die wichtigen Prozessanpassungen für den nächsten Sprint festgelegt.
In der Praxis
In der Praxis zeigt sich, dass eine gute Vorbereitung für das Release Planning viel Arbeit erspart. Hier können der Scrum Master und der Product Owner schon im Vorfeld das Ziel des Releases festlegen. Gute Anhaltspunkte und Planungsgrundlagen sind schon vorhandene Velocity-Kennzahlen aus vorangegangenen Sprints / Iterationen. Innerhalb dieses Meetings sollte jedoch folgendes, aufgrund der Veränderlichkeit des Backlogs, bedacht werden: Don’t go into too much detail (vgl [Baker]).
Wenn Schätzen zu einem größeren Akt wird macht man es zu einer Aufgabe im Scrum-Prozess und arbeitet es wie jeden andere Aufgabe ab. So ist es durchaus valide diese im Rahmen einer Proof-of-Concept-Implementierung zu erarbeiten. Diese PoC-Implementierung wird vor der eigentlichen User-Story-Umsetzung z.B. als Sprint 0, durchgeführt und erlaubt eine validere Schätzung des Aufwandes (vgl. [Waters], [Baker2]).
Ein Video zum Thema „Maximizing Value with Agile Release Planning“ findet sich hier (vgl. [Shore])
Im Lauf der Zeit haben sich folgende Zeitrahmen als grober Startpunkt eines eingespielten Scrum-Teams herausgestellt:
- Sprint Planning ca. 4 Stunden
- Sprint Review ca. 4 Stunden
- Retrospektive ca. 3 Stunden
- Daily Scrum: 15 Minuten
Literatur
[Baker] – Release Planning von Simon Baker [April 2006]
[Baker 2] – User stories part 3: Using spikes to help estimate user stories von Simon Baker [Februar 2006]
[Waters] – Agile Release Planning von Kelly Waters [Februar 2008]
[Shore] – Maximizing Value with Agile Release Planning von James Shore [März 2009]