Sprint Planning

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.

Sprint Planning 1 in der Praxis

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 in der Praxis

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.

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.

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

Hinweise:

Wenn Ihnen der Beitrag gefällt, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für Tipps aus der Praxis interessieren, dann testen Sie unseren beliebten Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter.

[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 ein Video über Sprint Planning von Mike Cohn.

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

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.