TopMenue

Sprint-Planning, Phase I

Dieser Beitrag befindet sich noch in Bearbeitung!

scrum.that.runs

Aufgabe Bestimmung und Planung der User-Stories, die im aktuellen Sprint umgesetzt werden sollen
Organisator Product-Owner
Teilnehmer Product-Owner, Entwicklungsteam, Scrum-Master.
Optional: Stakeholder, weitere Gäste
Zeitpunkt Zu Beginn jedes Sprints
Dauer ca. 2-4 Stunden

[Sprint-Planning I]

Aktive Teilnehmer  ^

Product-Owner
Der Product-Owner organisiert und moderiert diese Phase des Sprint-Planning-Meetings und lädt die Beteiligten dazu ein.

Voraussetzung für das Sprint-Planning ist ein vom ihm aktuell gepflegtes und priorisiertes Product-Backlog, aus dem er eine Anzahl der höchstpriorisierten und aus seiner Sicht als nächstes zu realisierenden User-Stories zu einem Selected-Backlog zusammengefasst hat. Wie viele wie große User-Stories der Product-Owner in das Selected-Backlog übernommen hat, ergibt sich aus der Erfahrung des Product-Owner und ggf. aus Schätzungen eines evtl. vorangegangenen Refinement-Meetings.

Entwicklungsteam
Die Aufgabe des Scrum-Masters ist, sicherzustellen, dass der Scrum-Prozess eingehalten wird und die Kommunikation zwischen den Beteiligten gut funktioniert. Darüber hinaus kann der Product-Owner ihm die Moderation des Meetings übertragen.

Scrum-Master
Die Aufgabe des Scrum-Masters ist, sicherzustellen, dass der Scrum-Prozess eingehalten wird und die Kommunikation zwischen den Beteiligten gut funktioniert. Darüber hinaus kann er das Meeting moderieren.

Gäste
Eventuelle Gäste (z.B. Stakeholder, Management) können vom Product-Owner zum ersten Teil des Meetings eingeladen werden, müssen sich jedoch passiv verhalten, da sie die Inhalte dieser Sprint-Planung bereits im Vorwege ausführlich mit dem Product-Owner abgesprochen haben; ein spontanes Eingreifen von ihnen an dieser Stelle würde den optimierten Verlauf des Planungsmeetings stören oder sogar gefährden. Sollten sie ausnahmsweise die Notwendigkeit eines Eingreifens oder einer Stellungnahme sehen, sollten sie dies dem jeweiligen Moderator (Product-Owner / Scrum-Master) signalisieren, der es dann im Ablauf berücksichtigt. Veränderungen an den zu besprechenden Inhalten sollten nur dann erfolgen, wenn sie grundlegender Natur sind und auch in diesem Fall sollten die entsprechenden User-Stories in das Product-Backlog zurückgestellt und zunächst erneut in angemessener Weise vom Product-Owner aufbereitet werden.

Das Selected-Backlog  ^

Das Selected-Backlog enthält alle User-Stories, die der Product-Owner im Sprint realisiert haben möchte; es handelt sich somit um eine Wunschliste. Die Menge der User-Stories im Selected-Backlog sind daher zunächst nur Vorschläge; wie viele und welche der User-Stories dieser Liste später wirklich in das Sprint-Backlog übernommen und im Sprint realisiert werden, entscheidet letztendlich das Entwicklungsteam (siehe Commitment).

Phase I im Detail

Schritt 1: Präsentation der Vision / des Themas des Sprints, Dauer: max. 15 Minuten  ^

Das Sprint-Planning beginnt damit, dass der Product-Owner die Sprint-Vision (siehe Sprint-Goal) und wie es sich in den Gesamtzusammenhang des Projektes einfügt, vorstellt. Dem Sprint eine Vision voranzustellen, ist vorteilhaft, weil das Entwicklungsteam dadurch zu einer übergeordnete Sicht und uz einem gemeinsamen Verständnis des Sprint-Ziels kommt, was sowohl das Verständnis des Zusammenspiels der einzelnen User-Stories und ihr Einfluss auf das Große und Ganze betrifft, als auch die Selbstorganisation der Teammitglieder im Entwicklungsprozess unterstützt. Dieser Schritt wird zwar von Scrum selbst nicht ausdrücklich gefordert, jedoch hat sich in der Praxis gezeigt, dass es den Sprintverlauf außerordentlich unterstützt, wenn dem Entwicklungsteam der übergeordnete Hintergrund des Sprints in Form einer Sprint-Vision präsentiert wird.

Schritt 2: Präsentation des Selected-Backlogs, Dauer: max. 30 Minuten  ^

Im Anschluss an die Einführung (Schritt 1) gibt der Product-Owner den Anwesenden (Entwicklungsteam, Scrum-Master und ggf. Gäste) im zweiten Schritt einen Überblick über den von ihm gewünschten Realisationsumfang des Sprint in Form einer Themenliste / Agenda, in der er die einzelnen User-Stories in Reihenfolge absteigender Priorität kurz vorstellt.

Dieser Teil ist ein reiner Vortrag durch den Product-Owner, der nicht durch technische oder fachliche Fragen unterbrochen werden sollte; lediglich grundsätzliche Verständnisfragen, etc., sollte er zulassen und beatworten. Da es sich zu diesem Zeitpunkt lediglich um die Bekanntgabe der Themenliste — also die Agenda der Planung — handelt und die einzelnen Punkte erst im nächsten Schritt Stück für Stück detailliert und erschöpfend durchgesprochen werden, sollten zu diesem Zeitpunkt tiefergehende Diskussion über die Inhalte vermieden werden.

Nach Abschluss dieses Schrittes sollte jeder Entwickler einen Überblick über die für die Realisierung im Sprint vorgeschlagenen User-Stories erhalten haben und sich in der Lage sehen, den nun folgende Vertiefungs- und Verfeinerungsschritt (Schritt 3) im Gesamtzusammenhang betrachten zu können.

Sollten die Entwickler zu diesem Zeitpunkt Hinweise oder Änderungswünsche bzgl. der Agenda haben, sollten sie sie dem Product-Owner vor dem Beginn des nächsten Schrittes mitteilen.

Schritt 3: Diskussionen über die User-Stories, Dauer: verbliebene Zeit der max. 4 Stunden  ^

Im dritten Schritt dieser Phase gehen der Product-Owner und das Entwicklungsteam die einzelnen User-Stories in der gleichen Reihenfolge (absteigende Priorität) detailliert, mit kurzer und möglichst flacher Diskussion durch, um die technischen und fachlichen Hintergründe der jeweiligen User-Stories zu durchleuchten und eine Vorstellung über die Machbarkeit der User-Story und den zu erwartenden Realisationsaufwand zu erhalten.

Die technische Planung der Umsetzung der User-Stories erfolgt später in der zweiten Phase des Sprint-Plannings, an dem dann hauptsächlich nur noch das Entwicklungsteam beteiligt ist.

Bearbeitung der Akzeptanzkriterien der User-Story  ^

Ist eine User-Story ausreichend abgeklärt, sollten die vom Product-Owner bereits vorbereiteten Akzeptanzkriterien gemeinsam mit dem Entwicklungsteam ggf. ergänzt und verfeinert werden, was im Idealfall bis hin zur (sprachlichen) Formulierung von konkreten Akzeptanztests, die später in der Abnahme verwendet werden können, ausgeweitet werden kann.

Schätzen des Realisationsaufwands der jeweiligen User-Stories  ^

Nun kann vom Entwicklungsteam der Realisationsaufwand der User-Story geschätzt werden.

Da es nicht möglich ist, den wirklich notwendigen Realisierungsaufwand exakt schätzen zu können, werden die Aufwände in Scrum nicht in Exaktheit vortäuschenden Stunden oder Minuten geschätzt, sondern in relativen Größenordnungen. Hierfür wird zunächst (einmalig) eine einfache User-Story definiert, die den Einheitswert darstellt und als Vergleich in allen zukünftigen Schätzungen herangezogen wird. Die Schätzungen erfolgen dann z.B. in Form einer begrenzten Fibonacci – Folge, z.B. 1 – 2 – 3 – 5 – 8 – 13 – 20 … usw., oder z.B. in Form von T-Shirt-Größen XS – S – M – L – XL – XXL … usw., denen dann die Zahlen 1 – 6 oder in einer anderen Zahlenreihe, z.B. Verdoppelung, 1 – 2 – 4 – 8 – 16 – 32, oder ähnlich, zugeordnet werden.

Diese Vorgehensweise wird angewandt, weil es sich beim Schätzen (!) nicht um die Abgabe einer exakten Prognose (z.B. 4 Stunden) handeln kann, sondern eben lediglich um eine ungefähre Schätzung der Größenordnung, da eine User-Story zu diffus und i.A. zu groß zum exakten Bestimmen des Realisationsaufwand ist und zu diesem Zeitpunkt der wirkliche Aufwand noch gar nicht bekannt sein kann. (siehe Schätzen, Planning-Poker).

Ist eine User-Story geschätzt und soll im Sprint realisiert werden, wird sie in das Sprint-Backlog übernommen.

Das Entwicklungsteam (und auch der Product-Owner) sollten die Summe der geschätzten Story-Points der in das Sprint-Backlog übernommen User-Stories immer im Auge behalten, um erkennen zu können, wann die „maximal realisierbare Menge an Aufgaben“ für den Sprint erreicht ist. Ist das der Fall, kann das Schätzen und dieser Schritt und damit auch diese Phase beendet werden; oft ist es aber sinnvoll – sofern Zeit ist und im Selected-Backlog noch ungeschätzte User-Stories vorhanden sind – auch noch einige weitere / die verbliebenen User-Stories zu schätzen, um ggf. die Füllung des Sprint-Backlogs ggf. optimieren zu können.

Sollten zu wenige User-Stories im Selected-Backlog vorhanden sein, kann der Product-Owner selbstverständlich spontan weitere der höchstpriorisierten User-Stories aus dem Product-Backlog in das Selected-Backlog übernehmen. Diese werden dann weiter durchgegangen und geschätzt, die Beteiligten der Meinung sind, dass sich im Sprint-Backlog eine ausreichende Menge an User-Stories für die Realisation im den anstehenden Sprint befinden oder die Zeit für diese erste Phase abgelaufen ist.

Variation der User-Stories, bis sich ein im realistisch umsetzbares Sprint-Backlog ergibt  ^

Zu jeder Zeit in dieser Phase können Product-Owner und Entwicklungsteam einvernehmlich ein Feintuning des Sprints vornehmen, indem die Menge oder die Reihenfolge der User-Stories oder die User-Stories selbst variiert werden, also z.B. auch, dass User-Stories wieder aus dem Sprint-Backlog entfernt und/oder durch andere User-Stories ersetzt werden. Welche User-Stories hierfür herangezogen werden, liegt ausschließlich in der Entscheidung des Product-Owner!

Selbstverpflichtung des Entwicklungsteams zur Erreichung des Ziels (Commitment)  ^

Ist das Schätzen einvernehmlich abgeschlossen, verpflichtet sich das Entwicklungsteam ausdrücklich mit der Abgabe des Commitment dazu, den gemeinschaftlich erarbeiteten Umfang des Sprint-Backlogs im Verlauf des Sprints zu realisieren.

Mit dem Commitment des Entwicklungsteams ist die Planung für den Product-Owner zunächst abgeschlossen. Er kann sich nun weiteren seiner zahlreichen Aufgaben widmen, sollte dem Entwicklungsteam — die im Anschluss an die Phase I die Phase II des Sprint-Plannings durchführen, jedoch zur kurzfristigen Beantwortung evtl. auftretender Detailfragen zur Verfügung stehen.

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1503130747DE