Sprint Planning Meeting: Definition, Ablauf & wichtige Tipps

Das Kick-Off eines jeden Sprints ist das Sprint Planning Meeting. Es dient dazu, das Arbeitspensum des Scrum-Teams für den kommenden Sprint festzulegen. Wie das Sprint Planning Meeting vom Product Owner vorbereitet werden muss, wer daran teilnimmt, wie der Ablauf ist und was das Team dabei beachten sollte, liest du in diesem Artikel.

Sprint Planning: Ziele & Teilnehmer des Meetings

Ein Sprint Planning Meeting hat zwei Ziele. Nach einem gelungenen Sprint Planning:

• sind sich Product Owner und Development Team über das Sprintziel (Outcome) einig
• und haben gsie emeinsam den Sprint Backlog gebildet. Der Sprint Backlog enthält alle Product Backlog Items, die im Sprint umgesetzt werden müssen, um das Sprintziel zu erreichen (Output).

Stellenweise wird Outcome und Output auch als MVP, Minimum Viable Product, zusammengefasst.

Wer lädt zum Sprint Planning ein?

Der Product Owner lädt das Entwicklungsteam und den Scrum Master zur Scrum Planning Session ein. Gibt es außerdem Stakeholder, die sich anschauen wollen, wie das Sprintziel lautet und welche Backlog Items bearbeitet werden, lädt der Product Owner auch sie ein.

Vorbereitung des Scrum Planning Meetings

Damit Product Owner und Entwicklungsteam die beiden Ziele des Planning Meetings erreichen, müssen einige Voraussetzungen geschaffen werden. Die folgenden vorbereitenden Schritte sind daher vor dem Sprint Planning im Scrum unerlässlich. Wenn du selbst als PO arbeitest oder dich aktuell auf die Rolle des Product Owners vorbereitest, kannst du diese Checkliste nutzen oder die unten aufgefügten Punkte nutzen.

• Der Product Owner hat ein Sprintziel (Outcome) definiert und die dazugehörigen Product Backlog Items (PBIs) ausgewählt.
• Die ausgewählten PBIs wurden ausreichend detailliert formuliert – am besten in Zusammenarbeit mit dem Entwicklungsteam, z. B. im Rahmen eines Product Backlog Refinements.
• Die ausgewählten PBIs wurden in eine Reihenfolge gebracht, nach der das Entwicklerteam sie bearbeiten wird. Hierbei sind technische Abhängigkeiten berücksichtigt.
• Das Team verfügt über eine Definition of Done (DoD). Diese liefert ein gemeinsames Verständnis dafür, „wann etwas fertig ist“.
• Die Kapazität des Teams für den nächsten Sprint wurde ermittelt, z. B. unter Berücksichtigung der durchschnittlichen Velocity der letzten Sprints und eventuell geplanten Urlaubs einzelner Teammitglieder.

Der Sprint Planning Ablauf

Ist das Sprint Planning wie beschrieben vorbereitet, kannst du dich mit deinem Scrum-Team an den eigentlichen Ablauf machen. Das Meeting verläuft nach der folgenden Sprint Planning Agenda:

• Der Product Owner stellt das Sprintziel und die dazugehörigen PBIs vor und beantwortet Verständnisfragen des Teams. Das Sprintziel sollte für alle Teammitglieder gut lesbar am Sprint Backlog dokumentiert werden.
• Sofern die PBIs noch nicht eingeschätzt sind, solltet ihr die Einschätzung jetzt vornehmen. Hat die Schätzung bereits stattgefunden, kann dein Team nach der detaillierten Diskussion zur Umsetzung nun die Schätzung verfeinern.
• Das Team macht gegenüber Product Owner und Stakeholdern eine Voraussage darüber, welche PBIs es zum Ende des Sprints gemäß der gemeinschaftlich verfassten DoD liefern wird. Auf diese Weise bildet sich der Sprint Backlog, in dem dokumentiert sein sollte, zu welchen PBIs sich das Entwicklungsteam verpflichtet hat und welche es optional zusätzlich bearbeiten wird.

Natürlich gibt es im Scrum auch für das Sprint Planning eine Timebox: Die Länge eines Sprint Plannings sollte nicht länger als einen Tag (Timebox: 8 Stunden) betragen.

Unterscheidung in Sprint Planning 1 und 2

Unser Praxis-Tipp: Häufig unterscheiden Scrum-Teams zwischen Sprint Planning 1 und 2:

• Sprint Planning 1 beschäftigt sich mit der Frage: Was wollen wir im kommenden Sprint angehen?
• Sprint Planning 2 behandelt die Frage: Wie wollen wir es angehen?

Die Timebox der beiden Plannings teilt sich übrigens nicht in jeweils 4 Stunden auf – stattdessen ist Planning 1 nach einem guten Refinement automatisch recht kurz, während der größere Teil der Timebox für Planning 2 benötigt wird.

Obwohl dies nicht verpflichtend ist, brechen einige Entwicklerteams im Scrum Sprint Planning 2 die Product Backlog Items in kleinere Arbeitspakete (Tasks) herunter. Dieser zweite Teil des Sprint Plannings findet häufig ohne den Product Owner statt.

Was sollte ein Team noch bei der Sprintplanung berücksichtigen?

Ein Entwicklungsteam wird in einem Sprint niemals ausschließlich an den gewählten Sprint Backlog Items arbeiten können, denn in jedem agilen Arbeitsumfeld gibt es zwischendurch Störungen, kleine Notfälle und dringende Support-Anfragen.

Aus diesem Grund lohnt es sich für dein Team, eine Art Puffer in die Sprints einzuplanen, die z. B. folgende Tätigkeiten einkalkuliert:

• Fixen operativer Probleme, z. B. wenn ein Server ausfällt
• Fixen kritischer Bugs
• First- oder Second-Level Tech-Support

Solche Puffer sorgen dafür, dass das Scrum Sprint Planning einen Backlog hervorbringt, den das Team auch tatsächlich schaffen kann, ohne sich von Störungen frustrieren zu lassen. Zudem zeigen unsere Studien, dass Teams mit einem Puffer im Verlauf der Zeit performanter werden. Das liegt u. a. daran, dass diese Teams häufiger ihre Sprintziele erreichen und somit häufiger Erfolgserlebnisse haben.

Die Ergebnisse der Sprintplanung

Wenn du und dein Team die folgenden Punkte als erledigt markieren könnt, wisst ihr, dass eure Sprintplanung erfolgreich war und ihr alles richtig gemacht habt:

• Das Scrum-Team hat ein gemeinsames Verständnis davon entwickelt, was im kommenden Sprint erreicht werden soll (Sprintziel).
• Durch die Diskussion des Entwicklungsteams untereinander habt ihr ein gemeinsames Verständnis davon, wie die jeweiligen PBIs umgesetzt werden sollen.
• Ihr habt ein sauber abgebildetes Sprint Backlog erstellt, welches die PBIs in der Reihenfolge des Product Backlogs enthält, eventuell sogar nach einem Task Breakdown inklusive dazugehöriger Tätigkeiten.

Der größte Fehler beim Sprint Planning Meeting

Manche Entwicklungsteams versteifen sich darauf, den perfekten Sprint Backlog zu erstellen, indem sie versuchen, jede noch so kleine Task zu identifizieren und akribisch genau einzuschätzen. Meist passiert das, wenn das Management die agile Arbeitsweise noch nicht vollständig durchdrungen hat und solche “exakten” Einschätzungen verlangt.

Da bei einer übertrieben genauen Schätzung im Sprint Planning Meeting zu viel Zeit verloren geht, sollte der Scrum Master dafür sorgen, dass das eigentliche Ziel des Plannings nicht verloren geht: nämlich die richtigen PBIs für den nächsten Sprint auszuwählen und gerade so viel darüber zu sprechen, dass das Team sich bereit fühlt, die Items zu bearbeiten.

Fazit zum Sprint Planning Meeting

Ein erfolgreiches Sprint Planning Meeting steht und fällt mit einer guten Vorbereitung wie dem Product Backlog Refinement. Das Sprint Planning Meeting wiederum liefert die Voraussetzung dafür, dass jeder im Team weiß, was im nächsten Sprint wie umgesetzt werden soll. Wenn der Sprint also gelingen und das Entwicklungsteam die PBIs erfolgreich und frustfrei bearbeiten soll, ist im Scrum das Planning Meeting absolut unverzichtbar.