t2informatik » Wissen kompakt » Sprint Planning

Was ist ein Sprint Planning?

Wer nimmt daran teil, welche Phasen gibt es und wie ist der ideale Ablauf?

Sprint Planning – Definition

Scrum beschreibt als agiler Prozess für Softwareentwicklung und Projektmanagement 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. Es ist ein Treffen zur Planung der Anforderungen und Arbeitspakete, die im aktuellen Sprint umgesetzt werden sollen. Voraussetzung für das Meeting ist ein gepflegtes und priorisiertes Product Backlog. Es dient als Quelle zur Erstellung eines Selected Backlogs mit den wichtigsten und am höchsten priorisierten Anforderungen. 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, entscheidet das Entwicklungsteam.

Teilnehmer am Sprint Planning

Beim Sprint Planning nimmt das Entwicklungsteam – 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 aber passiv verhalten. Idealerweise hat der Product Owner bereits vor dem Meeting mit den Stakeholdern ü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 das Sprint Planning, das Daily Scrum, das Sprint Review und die Retrospektive. Auch das Backlog Grooming bzw. Refinement wird regelmäßig durchgeführt. 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.

Scrum Whitepaper - t2informatik Download Vorschau

Jetzt das Scrum Whitepaper kostenlos downloaden.

Alles Wichtige über Scrum, die zentralen Begriffe, Rollen, Events und Herausforderungen auf 29 Seiten zum Mitnehmen.

Hier klicken »

Das Sprint Planning in der Praxis

Sprint Planning 1

Das Sprint Planning teilt sich in zwei Phasen bzw. Teile auf: Sprint Planning 1 und 2.  Das Sprint Planning 1 kümmert sich um „What“ – also darum, „was“ getan werden soll. Es setzt sich aus folgenden Schritten zusammen:

  • Vision des Sprints – vorgetragen durch den Product Owner. Durch die Vision erhält das Entwicklungsteam 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 Erreichung des Sprintziels hilft. Je länger ein Sprint dauert, desto wichtiger wird diese Orientierung. Aus der Vision entsteht das Sprint Goal.
  • Nennung der Items im Selected Backlog durch den Product Owner und anschließende Diskussion mit dem Entwicklungsteam. Hier geht es darum, fachliche und technische Hintergründe und Zusammenhänge zu erkennen und eine Vorstellung zur Machbarkeit der Anforderungen zu gewinnen.
  • Verfeinerung der Akzeptanzkritieren der User Storys, gegebenenfalls bereits Formulierung von konkreten Akzeptanztests.
  • Aufwandschätzung zur Realisierung der User Storys durch das Entwicklungsteam in Personentagen, Story Points oder T-Shirt Sizes.
  • Übernahme der besprochenen Anforderungen 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 des Entwicklungsteams, d.h. eine Verpflichtung des Teams die besprochenen Anforderungen 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 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 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 User Storys in Arbeitspakete – sprich Tasks. Idealerweise werden die Anforderungen nach ihrer Priorität in einzelne Aufgaben, die nicht länger als einen Arbeitstag dauern sollten, zerlegt. 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 selbstorganisierendes 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: „The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.“ In anderen Worten, pro einwöchigem Sprint empfiehlt der Scrum Guide 2 Stunden, bei einem zweiwöchigen Sprint also 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 das Sprint Planning:

  • Vereinbaren Sie einen Prozentsatz der Kapazität für Fehlerbehebungen und Support-Arbeiten.
  • Planen Sie mit effektiven Arbeitstagen, 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 besserer Software führt.

 

Wollen Sie mehr über Scrum erfahren?

Hier finden Sie Details zu Daily Scrums, Tipps und Tricks zum Sprint Review, verschiedene Methoden einer Retrospektive oder den idealen Ablauf eines  Scrum of Scrums.

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 Software-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.

Gerne stellen wir Ihnen Wissen, Erfahrung und 100% Leidenschaft für Ihre Softwareentwicklung und Anforderungsanalyse zur Verfügung. Wir helfen Ihnen bei der Erhebung, Strukturierung und Verwaltung von Anforderungen und achten dabei auf Konsistenz, Vollständigkeit und Nachvollziehbarkeit. Wir unterstützen Sie beim Identifizieren von technischen Zusammenhängen und berücksichtigen Stakeholder, Ziele und Randbedingungen. Und wir planen und steuern Ihre Projekte mit diesen Anforderungen auf Basis definierter Prozesse.

Hier erfahren Sie mehr zum Thema Softwareentwicklung »

Weitere Details und Hintergründe

Share This