Sprint Planning

• Das Sprint Planning findet einmal pro Sprint statt.
• Am Sprint Planning nimmt das gesamte SCRUM-Team teil, also der Product Owner, der SCRUM Master und die Developers.
• Das Sprint Planning dauert bei einem Sprint von 4 Wochen maximal 8 Stunden.
• Dauert der Sprint weniger als 4 Wochen, passt sich die Dauer des Sprint Plannings auch entsprechend proportional an und ist kürzer.
• Der SCRUM Master ist dafür verantwortlich, dass das Sprint Planning stattfindet und dass alle Mitglieder des SCRUM-Teams verstehen, was das Ziel des Events ist. Er ist zudem dafür verantwortlich, dass das Sprint Planning im vereinbarten Zeitfenster bezüglich der Dauer bleibt.
• Das Sprint Planning ist in 3 Teile gegliedert.

1. Teil: Warum ist dieser Sprint wertvoll ?

Im 1 Teil des Sprint Plannings geht es darum zu definieren, warum der Sprint wertvoll ist; also auch die Frage, was für ein Wert geschaffen werden soll. Im ersten Schritt stellt der Product Owner vor, wie der aktuelle Sprint den Wert und Nutzen des Produktes steigern kann. Dies macht er mithilfe eines Sprint-Ziel-Entwurfs - dieser wird dann im Verlauf des Sprint Plannings vom SCRUM-Team gemeinsam finalisiert. Es geht darum, das „Warum“ zu definieren und Transparenz zum Mehrwert des Sprints zu schaffen. Wichtig ist hierbei, dass insbesondere die Sicht der Stakeholder für das SCRUM-Team deutlich wird.

1. Teil: Was kann im kommenden Sprint umgesetzt werden ?

Der 2 Teil umfasst die Vorstellung der Backlog Items, die notwendig sind, um das Sprint-Ziel zu erreichen. Dies erfolgt durch den Product Owner gegenüber den Developers. Die Items, die umgesetzt werden sollen, hat der Product Owner bereits priorisiert, also nach Priorität der Abarbeitung geordnet. Das Product Backlog enthält demnach alle Items, die umgesetzt werden sollen, um das Gesamtprodukt zu entwickeln. Es geht darum, das „WAS“ zu besprechen; also darum, „WAS“ im kommenden Sprint umgesetzt werden kann. Der Product Owner stellt in einem ersten Schritt den Developers die notwendigen Backlog Items in Bezug auf das Sprint-Ziel vor. Hierbei können die Developers dann die Fragen stellen, die sie beantwortet wissen müssen, um abzuschätzen, welche der Backlog Items sie im nächsten Sprint umsetzen können.

Wichtig ist hierbei, dass das gesamte SCRUM-Team zusammenarbeitet mit dem Ziel, über ein gemeinsames Verständnis der Aufgaben des kommenden Sprints zu verfügen.

Hierbei ist es auch wichtig zu definieren, wann die Aufgaben beziehungsweise die Backlog Items fertig sind. Dazu dient ein gemeinsames Verständnis der „Definition of Done“ (siehe Abschnitt „Definition of Done“). Der Input für dieses Event ist das Product Backlog, in dem alle Produkteigenschaften zusammengefasst sind. Zudem auch der letzte Stand des Produktinkrements (liegt ab dem ersten Sprint vor beziehungsweise nach dem ersten Sprint), die geschätzte Kapazität der Developers im kommenden Sprint, und zusätzlich noch die vergangene Performance der Developers. Diese Input-Parameter erlauben es abzuschätzen, „was“ im kommenden Sprint geleistet werden kann. Die Entscheidung darüber, wie viele Items für das Sprint Backlog ausgewählt werden, liegt ganz allein bei den Developers. Nur die Developers können abschätzen, was im anstehenden Sprint geleistet werden kann. Während des Sprint Plannings formuliert das SCRUM-Team ein Sprint-Ziel. Das Sprint-Ziel ist ein Ziel, das erreicht wird, wenn alle Product Backlog Items im Laufe des Sprints geleistet wurden. Es gibt den Developers eine Orientierung dafür, warum sie das Produktinkrement entwickeln. Eine ausführliche Beschreibung des SprintZiels findest du in Abschnitt 3.4. Das Ergebnis dieses zweiten Teils des Sprint Plannings ist also, dass das Sprint-Ziel festgelegt wurde und dass die im kommenden Sprint zu leistenden Items festgelegt wurden.

1. Teil: Wie wird die gewählte Arbeit erledigt ?

Im 3 Teil des Sprint Plannings geht es darum, wie die zu leistende Arbeit im kommenden Sprint erledigt wird. Ziel dieses Teilschritts im Rahmen des Sprint Plannings ist, festzulegen, ob die ausgewählten Backlog Items geeignet sind, im kommenden Sprint auch wirklich umgesetzt zu werden.

Hauptergebnis beziehungsweise Artefakt des Sprint Plannings Events ist das Sprint Backlog. Das Sprint Backlog umfasst die aus den Product Backlog für den Sprint ausgewählten Backlog Items und eine Planung, wie diese im Rahmen des Sprints umgesetzt werden.

Es geht also um das „WIE“ wird im Rahmen des Sprints das umgesetzt, was umgesetzt werden muss? Hierfür werden für jedes Backlog Item Aufgaben beziehungsweise Tasks definiert. Diese Aufgaben dienen dazu, jedes einzelne Backlog Item so zu konkretisieren, dass die Developers genau wissen, welche Aufgaben und Tätigkeiten zur Erledigung des jeweiligen Backlog Items zu erfüllen sind.

Die Tasks sind notwendig, um die operative Arbeit der Developers nach Beendigung des Sprint Plannings zu ermöglichen. Hierbei ist es wichtig, dass jeder Task so definiert bzw. formuliert wird, dass er an maximal einem Tag erledigt werden kann. Wäre eine Aufgabe zu groß für einen Tag, so muss sie gemäß SCRUM in weitere Unteraufgaben unterteilt werden, so lange, bis diese an einem Tag erfüllt werden können.

Zudem sollten die Tasks so formuliert werden, dass für jedes Mitglied der Developers ganz eindeutig ist, WAS zu tun ist. Und dies unabhängig davon, wer der Developers diese Aufgabe letztendlich übernehmen wird.