Sprint Planning

Was ist ein Sprint Planning, wer sind die Teilnehmer, welche Phasen gibt es und wie ist der ideale Ablauf?

Sprint Planning Definition

Scrum ist ein Framework für die Software-, Produkt- und Dienstleistungsentwicklung und beschreibt ein inkrementelles, iteratives Vorgehen. Eine Iteration wird als Sprint bezeichnet. Zu Beginn eines Sprints findet das Sprint Planning (auch als Sprint Planning Meeting oder Sprint-Planungssitzung bezeichnet) als Kick-off statt.

Das Sprint Planning ist ein Treffen zur Definition eines „wertvollen“ Sprint-Ziels als Etappe zur Erreichung des Produkt-Ziels und zur Planung der Backlog Items, die im aktuellen Sprint umgesetzt werden sollen. Struktur erhält das Meeting durch drei Fragen:

  • Warum ist dieser Sprint wertvoll?
  • Was kann in diesem Sprint umgesetzt werden?
  • Wie werden die ausgewählten Sprint Backlog Items umgesetzt?

Einfach ausgedrückt: Die Planung initiiert den Sprint und legt die Arbeiten fest, die innerhalb des aktuellen Sprints umgesetzt werden sollen.   

Sprint Planning - Wissen kompakt - t2informatik

Voraussetzung für das Sprint Planning ist ein gepflegtes und priorisiertes Product Backlog. Es dient als Quelle zur Erstellung einer Auswahl mit den wichtigsten und am höchsten priorisierten Backlog Items. Die Auswahl wird häufig auch als Selected Backlogs bezeichnet.¹ Das Selected Backlog ist quasi eine Wunschliste des Product Owners. Wie viele und welche Backlog Items ins Sprint Backlog aufgenommen und in der Folge tatsächlich umgesetzt werden, entscheiden die Entwickler gemeinsam.

Teilnehmer am Sprint Planning

Bei der Sprint Planung nimmt das Scrum Team – also alle Entwickler, der Scrum Master und der Product Owner – teil. Organisiert wird das Meeting vom Product Owner, moderiert vom Scrum Master, der für die Einhaltung des vereinbarten Ablaufs und die Kommunikation zwischen den Beteiligten verantwortlich ist.

Stakeholder wie bspw. Anwender, Partner, Vertreter aus Vertrieb oder Marketing können zum Sprint Planning eingeladen werden, sie sollten sich jedoch eher etwas passiv verhalten und sich als Ratgeber verstehen. Idealerweise hat der Product Owner bereits vor dem Meeting mit den Stakeholdern und den Entwicklern über die Inhalte und die Bedeutung der Anforderungen gesprochen.

Sprint Planning als Scrum Event

Scrum ist ein kommunikativer Prozess mit verschiedene Events, die innerhalb eines Sprints durchgeführt werden. Dazu gehören neben dem Sprint Planning, das Daily Scrum, das Sprint Review und die Retrospektive. Auch das Backlog Refinement wird regelmäßig durchgeführt, auch wenn es nach dem Scrum Guide nicht als Event gilt.

Die Anzahl der Events zeigt, dass Kommunikation, die Auseinandersetzung mit der Entwicklung, das Arbeiten an gemeinsam vereinbarten Zielen sehr wichtig sind. Kein Event ist dabei wichtiger als ein anderes, denn stets werden eigene Ziele und damit ein konkreter Zweck verfolgt.

Die Sprint Plannung in der Praxis

Sprint Planning 1

Das Sprint Planning teilt sich in der Praxis meist in zwei Phasen bzw. Teile auf: Sprint Planning 1 und 2.  Das Sprint Planning 1 kümmert sich um das „Why“ und das „What“ – also darum, „warum“ der Sprint einen Wert besitzt und „was“ im Sprint getan werden soll. Es setzt sich aus folgenden Schritten zusammen:

  • Der Product Owner schlägt vor, wie das zu entwickelnde Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. In machen Publikationen wird auch von der Vision des Sprints gesprochen. Durch die Vision erhalten die Entwickler eine übergeordnete Sicht und ein besseres Verständnis, worum es im nächsten Sprint gehen wird. Auch wenn der Scrum Guide diesen Schritt nicht explizit fordert, so zeigt die Praxis, dass die Orientierung an der Vision dem Team bei der Definition und der späteren Erreichung des Sprint-Ziels hilft. Je länger ein Sprint dauert, desto wichtiger wird diese Orientierung. Aus der Vision entsteht das Sprint-Ziel und das Sprint-Ziel ist eine Etappe auf dem Weg zum Produkt-Ziel.
  • Nennung der Items – als Selected Backlog – durch den Product Owner und anschließende Diskussion mit Entwicklern mit dem Ziel, fachliche und technische Hintergründe sowie Zusammenhänge zu erkennen, und eine Vorstellung zur Machbarkeit der Inhalte zu gewinnen.
  • Verfeinerung der Akzeptanzkriterien der Items – die bspw. als User Storys vorliegen können. Ggf. werden auch bereits konkrete Akzeptanztests formuliert.
  • Aufwandschätzung zur Realisierung der Items durch die Entwickler bspw. in Story Points, Personentagen oder T-Shirt Sizes.²
  • Übernahme der besprochenen Items in das Sprint Backlog unter Beachtung der maximal zu realisierenden Menge an Aufgaben. Ist das Sprint Backlog „voll“ kann die Schätzung von weiteren Anforderungen auf das nächste Sprint Planning verschoben werden.
  • Commitment (also die Verpflichtung) der Entwickler  das Sprint-Ziel gemeinsam zu erreichen und die besprochenen Inhalte im Laufe des Sprints zu realisieren.

Mit dem Commitment des Teams endet Phase 1 des Sprint Plannings. 

Sprint Planning 2

Mit dem Commitment der Entwickler ist die Aufgabe des Product Owners beim Sprint Planning abgeschlossen. In Teil 2 des Meetings diskutieren die Entwickler, meist ohne den Product Owner, der aber für Rückfragen erreichbar sein sollte, und ohne die möglicherweise anwesenden Stakeholder, über die technischen Details der zu realisierenden Sprint Backlog Items bzw. User Storys. Das Sprint Planning 2 beschäftigt sich mit dem „How“, also der Frage, „wie“ die vereinbarten Anforderungen umgesetzt werden sollen. Folgende Schritte werden durchgeführt:

  • Gliederung der Items in Arbeitspakete – sprich Tasks. Idealerweise werden die Anforderungen nach ihrer Priorität in einzelne Aufgaben zerlegt, die nicht länger als einen Arbeitstag dauern sollten. Zeitliche und technische Abhängigkeiten sollten möglichst vermieden werden, um die parallele Bearbeitung von Tasks zu ermöglichen. In der Praxis kann es nützlich sein, manche Anforderungen erst im Laufe des Sprints iterativ zu zerlegen, um so neue Erkenntnisse nutzen zu können. Eine namentliche Zuordnung der Tasks auf einzelne Entwickler wird nicht vorgenommen.
  • Visualisierung der Tasks mit einem Taskboard. Hier unterscheiden sich die Ansätze: entweder wird mit einem physikalischen Taskboard zur Umsetzung der Storys und Tasks gearbeitet oder eine Software kommt zum Einsatz. Die Haptik der Story- und Task-Karten spricht für die physikalische Lösung, die Nachvollziehbarkeit und Revisionssicherheit für den Einsatz einer Software.
  • Entwicklung einer Realisierungsstrategie, bspw. das Festlegen von Klassen, Interfaces, Testcases und Unit-Tests.

Am Ende von Phase 2 sollte das Team in der Lage sein, dem Product Owner und dem Scrum Master zu erklären, wie er als selbstmanagendes Team arbeiten will, um das Sprint Goal zu erreichen und das erwartete Inkrement zu erstellen.

Timeboxing im Sprint Planning

Timeboxing ist ein zentrales Element in Scrum. Der Scrum Guide sagt in Bezug auf das Sprint Planning folgendes: „Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter“. Daraus ergibt sich eine Timebox pro einwöchigem Sprint von 2 Stunden, bei einem zweiwöchigen Sprint von 4 Stunden, usw. Die Stunden sollten dabei auf die beiden Planungsphasen gleich verteilt werden, also bei 8 Stunden für einen vierwöchigen Sprint 4 Stunden für Spint Planning 1 und 4 Stunden für Sprint Planning 2. Es ist die Aufgabe des Scrum Masters, für die Einhaltung der Timebox zu sorgen.

Diese Zeitangaben sind als Orientierung zu verstehen – Unternehmen haben die Freiheit andere Zeiten zu definieren. Im Vordergrund beim Sprint Planning sollte aber die Definition der Arbeitspakete zur Realisierung der vereinbarten Anforderungen stehen und nicht die Zeit, die möglicherweise bei der Planung gespart werden könnte.

Tipps und Tricks beim Sprint Planning

Es gibt eine Reihe von Erfahrungen, die Teams im Laufe einer Entwicklung sammeln. So werden sie besser beim Schätzen von Aufwänden oder können Störungen leichter vorhersehen. Hier finden Sie einige Tipps für die Sprint Planung:

  • Vereinbaren Sie einen Prozentsatz der Kapazität für Fehlerbehebungen und Support-Arbeiten.
  • Berücksichtigen Sie bei der Planung effektive Arbeitstage. Notieren Sie sich die freien Tage des Teams, Feiertage oder andere Ereignisse, die sich auf die Sprint-Lieferung auswirken könnten.
  • Manche Organisationen nutzen Fälligkeitsdaten, denn die Verwendung von Fälligkeitsterminen kann ein guter Mechanismus sein, um den Fortschritt voranzutreiben und zu verfolgen. Zusätzlich kann er nützlich für Tests und die Stakeholderkommunikation sein.³
  • Stellen Sie sicher, dass Sie eine Definition of Done nutzen, da dies am Ende jedes Sprints zu einem besseren Inkrement führt.

 

Sprint Planning Guide als Download

Jetzt den Sprint Planning Guide kostenlos downloaden.

Alles Wichtige zur Sprint Planung auf einen Blick.

  • Definition und Voraussetzung
  • Teilnehmer
  • Phasen, Schritte und Timeboxing
  • Tipps und Tricks
  • Herausforderungen

Wissen auf 7 Seiten zum Mitnehmen.

Herausforderungen für Unternehmen

Die Planung von potenziell lieferbaren Inkrementen

Es ist schwierig, die Zukunft vorherzusagen, trotz aller Erfahrungen und Techniken. Die Realität ist, dass selbst die Planung eines einfachen Softwareentwicklungsprojekts eine Herausforderung ist. Es gibt viele verschiedene Variablen, die berücksichtigt werden müssen, und sehr leicht kann es passieren, dass der Aufwand zur Realisierung einer Anforderung falsch eingeschätzt wird. In der Folge schaffen es Unternehmen oft nicht, Zusagen zu halten. Teams unterschätzen die Komplexität bei der Entwicklung von Lösungen, Zusammenhänge bei Anforderungen werden übersehen oder technische Schwierigkeiten lassen sich schlicht nicht einfach lösen. Die typische Projektplanung verwendet Puffer, um das Unerwartete zu berücksichtigen. Die zugrundeliegende Hoffnung ist, dass der Puffer groß genug ist und dass das Unerwartete nicht eintrifft. Wie können Sie diesen Fehler vermeiden? Scrum definiert die Erstellung von potenziell lieferbaren Inkrementen am Ende eines Sprints. Damit minimieren Sie das Risiko, denn wenn etwas wirklich Unerwartetes passiert, besteht so noch die Möglichkeit, einen Nutzen aus dem zu ziehen, was bereits entwickelt wurde.

Impuls zum Diskutieren:

Wie wichtig ist aus Ihrer Sicht das „Why“ und damit einhergehend das Product Goal für das Sprint Planning?

Hinweise:

[1] Den Begriff „Selected Backlog“ finden Sie nicht im Scrum Guide.
[2] Da sich der Scrum Guide sich nicht zur Schätzung von Backlog Items äußert, finden Sie auch die Begriffe Story Points, Personentage oder T-Shirt Sizes nicht im Guide.
[3] Fälligkeiten sind natürlich auch kein Bestandteil des Scrum Guides.

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

Wissen kompakt: Wie funktioniert Scrum?

Wie funktioniert Scrum?

Wissen kompakt: Wie gelingt der Umgang mit Impediments?

Wie gelingt der Umgang mit Impediments?

Wissen kompakt: Wie ist der ideale Ablauf beim Scrum of Scrums?

Wie ist der ideale Ablauf beim Scrum of Scrums?