Sprint-Planning

Dieser Beitrag befindet sich noch in Bearbeitung!

Scrum ist der Rahmen, Scrumcess der Prozess

Das Sprint-Planning ist das Kern-Planungsmeeting in Scrum.
AufgabePlanung der Anforderungen und Arbeitspakete, die im aktuellen Sprint umgesetzt werden sollen
OrganisatorProduct-Owner
TeilnehmerEntwicklungsteam, Scrum-Master, Product-Owner.
Optional: Stakeholder, weitere Gäste
ZeitpunktZu Beginn jedes Sprints
Dauerca. 4-8 Stunden
Aktive Teilnehmer

Der Product-Owner organisiert das Sprint-Planning-Meeting und lädt dazu ein.

Aktive Teilnehmer des Sprint-Planning sind
  • der Product-Owner,
  • das Entwicklungsteam und
  • der 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

Gäste (z.B. Stakeholder) können (zum ersten Teil des Meetings) eingeladen werden, jedoch müssen sie sich passiv verhalten. Sie haben die Inhalte dieser Sprint-Planung bereits im Vorwege ausführlich mit dem Product-Owner abgesprochen; würden sie an dieser Stelle eingreifen und Veränderungen an den besprochenen Inhalten verlangen, wäre die Vorbereitung des Product-Owner hinfällig.

Vorrausetzung für das Sprint-Planning

Voraussetzung für das Sprint-Planning ist ein vom Product-Owner aktuell gepflegtes und priorisiertes Product-Backlog, aus dem der Product-Owner eine Anzahl der höchstpriorisierten, als nächstes zu realisierenden Anforderungen zu einem Selected-Backlog zusammengefasst hat. Wie viele wie große Anforderungen 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 Estimation-Meetings.

Das Selected-Backlog

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

Das Sprint-Planning im Überblick

Das Sprint-Planning teilt sich in 2 Phasen auf.

[Sprint-Planning]

In der ersten Phase, die wiederum in drei Schritten durchgeführt wird, gehen der Product-Owner und das Entwicklungsteam die vorgeschlagenen Anforderungen detailliert durch, wobei das Entwicklungsteam den jeweiligen Realisationsaufwand einer jeden Anforderung schätzt. Das Entwicklungsteam legt fest, wie viele und welche der vorgeschlagenen Anforderungen aus dem Selected-Backlog in das Sprint-Backlog übernommen werden und verpflichtet sich am Ende dieser Phase dazu, die in das Sprint-Backlog übernommen Anforderungen bis zum Ende des Sprints vollständig fertig und abschließend zu realisieren (siehe Commitment).

In der zweiten Phase des Sprint-Planning zieht sich das allein Entwicklungsteam zurück und diskutiert Entwicklungsteam-intern die Realisierung der einzelnen Anforderungen und zerlegt sie in einzelne Tasks. Zwar wohnt der Product-Owner dieser zweiten Phase nicht automatisch bei, sollte aber für evtl. Rückfragen des Entwicklungsteams direkt und kurzfristig erreichbar sein.

Das Sprint-Planning im Detail

Teil 1, Briefing & Analyse, ca. 2 – max. 4 Stunden

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

Das Sprint-Planning beginnt damit, dass der Product-Owner die Vision des Sprints (siehe Sprint-Goal) und wie es sich in den Gesamtzusammenhang des Projektes einfügt, vorstellt. Dem Sprint eine Vision voranzustellen, ist insofern vorteilhaft, dass das Entwicklungsteam eine übergeordnete Sicht und ein gemeinsames Verständnis des Ziels des Sprints erhält, was sowohl das Verständnis des Zusammenspiels der einzelnen Anforderungen 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 Anforderungen 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 Anforderungen 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 Anforderungen, Dauer: verbliebene Zeit der max. 4 Stunden

Im dritten Schritt dieser Phase gehen der Product-Owner und das Entwicklungsteam die einzelnen Anforderungen 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 Anforderungen zu durchleuchten und eine Vorstellung über die Machbarkeit der Anforderung und den zu erwartenden Realisationsaufwand zu erhalten.

Die technische Planung der Umsetzung der Anforderung(en) 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 Anforderung

Ist eine Anforderung 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 Anforderungen

Nun kann vom Entwicklungsteam der Realisationsaufwand der Anforderung 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 Anforderung 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 Anforderung 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 Anforderung 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 Anforderungen 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 Anforderungen vorhanden sind – auch noch einige weitere / die verbliebenen Anforderungen zu schätzen, um ggf. die Füllung des Sprint-Backlogs ggf. optimieren zu können.

Sollten zu wenige Anforderungen im Selected-Backlog vorhanden sein, kann der Product-Owner selbstverständlich spontan weitere der höchstpriorisierten Anforderungen 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 Anforderungen für die Realisation im den anstehenden Sprint befinden oder die Zeit für diese erste Phase abgelaufen ist.

Variation der Anforderungen, 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 Anforderungen oder die Anforderungen selbst variiert werden, also z.B. auch, dass Anforderungen wieder aus dem Sprint-Backlog entfernt und/oder durch andere Anforderungen ersetzt werden. Welche Anforderungen 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 aber zur kurzfristigen Beantwortung evtl. auftretender Detailfragen zur Verfügung stehen.

Teil 2, Zerlegung in Arbeitspakete, ca. 2 – 4 Stunden

Diskussion des Entwicklungsteam über die technischen Details

In der zweiten Phase des Sprint-Plannings diskutiert das Entwicklungsteam für sich und ohne Gäste in „Klausur“ über die technischen Details der zu realisierenden Anforderungen.

Zerlegung der Anforderungen in Arbeitspakete (Tasks), keine Zuordnung zu Teammitgliedern

Nun werden die Anforderungen (ebenfalls in Reihenfolge absteigender Priorität) in einzelne Arbeitspakete zerlegt, deren jeweilig geschätzte Realisation einen Zeitrahmen von einem Arbeitstag nicht überschreiten sollte. Die Arbeitspakete, die weiterhin ihrer Ursprungs-Anforderung zugeordnet bleiben, werden nach technischen und fachlichen Gesichtspunkten (z.B. Gewichtung oder Abhängigkeiten) geordnet, wobei zeitliche („Arbeitspaket A soll zuerst realisiert werden, dann erst Arbeitspaket B“) oder technische / fachliche („Arbeitspaket A muss vor Arbeitspaket B realisiert werden, da der Code von Arbeitspaket B auf dem Code / der Existenz von Arbeitspaket A basiert“) Abhängigkeiten möglichst vermieden werden sollten, um die Möglichkeit der parallelen Bearbeitung der Arbeitspakete zu fördern.

Sind Abhängigkeiten vorhanden und unvermeidlich, sollten diese bereits in der Beschreibung des/der Arbeitspakete dokumentiert werden.

Das Entwicklungsteam entwickelt eine Strategie für die Realisation

Die Planungstiefe sollte dabei nicht zu tief angelegt sein, genauso sollte in dieser Phase noch kein produktiver Code erstellt werden, um der Kreativität des späteren Realisierers nicht vorzugreifen oder ihn zu beeinflussen; in der Praxis hat sich jedoch bewährt, ein rudimentäres Konstrukt aus Klassen, Interfaces und evtl. sogar Unit-Tests zu erstellen, das einen ersten gemeinsamen Rahmen und eine Kommunikationsbasis für die Entwickler darstellt.

Ebenso hat es sich bewährt, in dieser Phase iterativ voranzuschreiten, d.h. die Anforderungen gemeinsam zunächst nur grob zu zerlegen, um sich dann in separaten Gruppen an die weitere und detaillierte Zerlegung der Anforderungen und Arbeitspakete zu machen, um auch diesen Prozess parallelisieren zu können.

Zur Zerlegung der Anforderungen in Arbeitspakete gehört selbstverständlich auch, erste Test-Cases zu definieren, bzw. vielleicht sogar zu formulieren und im Arbeitspaket zu notieren, um dem späteren Realisierer aus dem Team heraus einen ersten Ansatz für mögliche Unit-Tests zu liefern.

Bei alledem wird zu dieser Zeit noch keine Zuweisung von Arbeitspakete oder gar Anforderungen zu Entwicklern vorgenommen; an dieser Stelle geht es ausschließlich um die Planung und die Vorbereitung der Realisation.

Anwesenheit des Product-Owner optional, Erreichbarkeit für Fragen jedoch notwendig

Auch wenn der Product-Owner an dieser vom Entwicklungsteam allein und in eigener Verantwortung durchgeführten Phase nicht direkt beteiligt ist, kann und wird es im Allgemeinen vorkommen, dass im Zuge der Zerlegung der Anforderungen in Arbeitspakete Fragestellungen auftauchen, die nur vom Product-Owner beantwortet und / oder entschieden werden können. Damit es im Laufe des Zerlegungsprozesses nicht zu Verzögerungen kommt (was auch gar nicht im Interesse des Product-Owner liegen kann), sollte er dem Team in dieser Phase für eine kurzfristige Klärung solcher Fragen zeitnah für ein Gespräch zur Verfügung stehen.

Der Tag / die Kraft ist aufgebraucht, aber noch Anforderungen zu bearbeiten?

Ist die Zerlegung der Anforderungen in Arbeitspakete am Ende des Arbeitstages oder der geistigen Kräfte noch nicht abgeschlossen, sollte auch diese Phase (nach insgesamt schätzungsweise ca. 8 Stunden Arbeit) trotzdem abgebrochen werden. Da, wie in Scrum üblich, die höchstpriorisierten Anforderungen zuerst bearbeitet wurden, sollte das Entwicklungsteam die Zerlegung beenden und am nächsten Tag oder zu einem späteren Zeitpunkt — ggf. mit verkleinerter Mannschaft — weiterführen.

Tasks an das Story-Board hängen

Sind alle oder ein Teil der Anforderungen in Arbeitspakete zerlegt und diese Daten im entsprechenden Verwaltungssystem hinterlegt (z.B. Excel, TFS oder andere), etc., werden die Anforderungen und ihre Arbeitspakete in Form von Story-, bzw. Task-Cards ausgedruckt und an das Story-Board gehängt (oder, wenn es ein elektronisches Verwaltungssystem gibt, ebenfalls dort hinterlegt).

Auch der Prozess der Zerlegung der Anforderungen in Arbeitspakete kann selbstverständlich als iterativer Prozess durchgeführt werden, d.h., es werden vom Entwicklungsteam zunächst nur die höchstpriorisierten Anforderungen bearbeitet, damit sich ein anderer Teil des Entwicklungsteams bereits an die Realisation machen kann, während sich der erste Teil des Entwicklungsteams weiter mit der Zerlegung und Planung beschäftigt, oder eine andere, vom Entwicklungsteam favorisierte Variante des Prozesses wird durchgeführt; dabei muss jedoch im Auge behalten werden, dass der gewählte Weg nicht zu Stillständen oder Leerläufen im Entwicklungsprozess führt, z.B., weil Fragen zu einem Zeitpunkt auftreten, wo der Product-Owner nicht (mehr) zur Verfügung steht, etc.

Der Scrum-Master moderiert die Planungs-Meetings und unterstützt im gesamten Prozess die Zusammenarbeit innerhalb des Entwicklungsteams und die Kommunikation zwischen Entwicklungsteam und Product-Owner.

Ist die Realisierung zumindest eines Teil der Anforderungen und Arbeitspakete (vorläufig) abschließend geplant, kann die Realisierung beginnen, indem die Entwickler sich Arbeitspakete nehmen (am Story-Board ihren Namen auf die Karte schreiben und / oder sich im Verwaltungssystem in der entsprechenden Karte eintragen) und mit ihrer Realisierung beginnen.

[zurück zum Seitenanfang]


Comments are closed.

V1710260636DE