Scrum im Selbststudium – Teil 12: Sprint Planning – Planung der Arbeit des Sprints


Willkommen zum 12. Teil der „Scrum im Selbststudium“-Artikelreihe. Die Übersicht zu allen Teilen findest du am Ende dieses Beitrags.

Jeder Sprint in Scrum beginnt damit, dass das Scrum Team einen grundlegenden Plan für den kommenden Sprint erstellt.

„Das Sprint Planning initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt. Dieser resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt.“

Scrum Guide, 2020

Im Sprint Planning beantwortet das Scrum-Team gemeinsam drei Fragen. Die Antworten stellen das Sprint Backlog dar: Es umfasst das Sprint‐Ziel, die für den Sprint ausgewählten Product‐Backlog‐Einträge und den Plan für deren Lieferung.

Das Sprint Planning im Scrum-Kreislauf (Bild: Scrum.org, Bearbeitung: S. Flossmann).

Die erste und wichtigste Frage im Sprint Planning lautet immer:

1. Warum ist dieser Sprint wertvoll?

Ohne ein Ziel gibt es keinen klaren Zweck, der die Mitglieder motiviert, während des Sprints zusammenzuarbeiten.

Das Ziel eines Sprints kann viele Gestalten annehmen:

Es kann das Ziel sein, eine Reihe von Funktionen zu liefern, die ein bestimmtes Problem lösen. Es kann darum gehen, ein Bedürfnis einer Gruppe von Stakeholdern zu befriedigen. Oder es kann eine Hypothese sein, die der Product Owner mit dem Inkrement, das aus dem Sprint hervorgeht, verifizieren möchte.

Deshalb schlägt der Product Owner vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Dann arbeitet das gesamte Scrum-Team zusammen, um ein Sprint‐Ziel zu definieren, das verdeutlicht, warum der Sprint für die Stakeholder wertvoll ist. Spätestens am Ende des Sprint-Planning-Events muss das Sprint‐Ziel finalisiert sein.

2. Was kann in diesem Sprint abgeschlossen (Done) werden?

Das Team arbeitet gemeinsam an der Verfeinerung dieses Ziels. Das Ziel muss sowohl wertvoll als auch innerhalb des Zeitrahmens eines Sprints realisierbar sein. Die Entwickler arbeiten mit dem Product Owner zusammen, um die Arbeit aus dem Product Backlog auszuwählen, die innerhalb des Sprints stattfinden soll, um das gewünschte Ziel zu erreichen. Dabei kann das Product Backlog bei Bedarf neu geordnet werden.

3. Wie wird die ausgewählte Arbeit erledigt?

Für jeden ausgewählten Product‐Backlog‐Eintrag planen die Entwickler nun die notwendige Arbeit, um ein Inkrement zu erstellen, welches die Definition of Done erfüllt.

Dies geschieht oft durch Zerlegung von Product‐Backlog‐Einträgen in kleinere Arbeitseinheiten von einem Tag oder weniger. Wie dies geschieht, entscheiden nur die Entwickler.

„Niemand sonst sagt ihnen, wie sie Product‐Backlog‐Einträge in Increments von Wert umwandeln sollen.“

Scrum Guide, 2020

Dieser Plan wird normalerweise in einer Arbeitsaufteilung für die ersten Tage des Sprints festgehalten. Im weiteren Verlauf des Sprints übersetzen die Entwickler diesen groben Plan, wie er durch das Sprint-Ziel und das Sprint Backlog vorgegeben ist, in einen konkreteren Plan. Dieser Plan beschreibt dann, wie sie zusammenarbeiten, um das Ziel zu erreichen. Die minimale Möglichkeit, diesen Plan zu konkretisieren, stellt das Daily Scrum dar.

Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event in der Regel kürzer.

Ausblick: Im nächsten Teil schauen wir uns an, welche Funktion das Event des Daily Scrums übernimmt.

Wenn du Fragen hast, schreibe sie gerne in die Kommentare hier im Blog oder auf unserem Colenet-Linkedin-Account.

Hier findest du alle Teile der Reihe „Scrum im Selbststudium“:

Teil 1: Agile Projekte sind erfolgreicher 

Teil 2: Scrum in 11 Schritten im Schnelldurchlauf erklärt

Teil 3: Warum ist die regelmäßige Überprüfung und Anpassung erfolgversprechender als Vorabanalyse und detaillierte Planung?

Teil 4: Zur Lösung komplexer Probleme hat sich ein empirischer Ansatz bewährt

Teil 5: Die Grundlage eines funktionierenden empirischen Prozesses ist Vertrauen

Teil 6: Die Scrum Artefakte stellen Transparenz her

Teil 7: Die mögliche Zukunft – Das Product-Backlog

Teil 8: Die Gegenwart – Das Sprint Backlog

Teil 9: Die Vergangenheit – Das Produkt-Inkrement

Teil 10: Scrum Events erlauben, die Artefakte zu überprüfen und anzupassen

Teil 11: Sprint – Erstellung eines Inkrements

Teil 12: Sprint Planning – Planung der Arbeit des Sprints

Teil 13: Daily Scrum – Tägliche Überprüfung des Fortschritts in Richtung des Sprint‐Ziels und Justierung der geplanten Arbeit

Teil 14: Sprint Review – Überprüfung der Sprint-Ergebnisse und weitere Planung

Teil 15: Sprint Retrospektive – Aus dem vergangenen Sprint lernen und Verbesserungen planen

Teil 16: Das Scrum-Team und seine Verantwortung

Teil 17: Der Product Owner maximiert den Wert des Produkts

Teil 18: Die Entwickler schaffen jeden Sprint ein nutzbares Inkrement

Teil 19: Der Scrum Master verantwortet die Effektivität des Scrum-Teams

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert