Sprint Planning - Die Sprint Planung in Scrum richtig und erfolgreich gestalten.

In der Sprint Planung in Scrum wird der kommende Sprint geplant. Dabei geht es um zwei zentrale Fragen: Wie viel kann in dem Sprint umgesetzt werden und wie konkret sieht diese Arbeit aus?

Die Sprint Planung in der Übersicht

Die Sprint Planung oder das Sprint Planning bezeichnet in Scrum eines von 5 Events, die es im agilen Framework gibt. Dabei ist die Sprint Planung das erste Event im Sprint. Zuvor hat die Sprint Retrospektive stattgefunden und im Anschluss findet das erste Daily Scrum statt.

Entwicklungsteam und Product Owner

Das Entwicklungsteam und der Product Owner sind die beiden wichtigsten produktbezogenen Akteure in der Sprint Planung

Plan und Ziel für den Sprint festlegen

Das Sprint Ziel und die Planung der Aufgaben, die innerhalb des nächsten Sprints anfallen, werden in der Sprint Planung bestimmt.

Was und wie viel werden wir schaffen?

Welche Menge an Aufgaben trauen wir uns im Sprint zu und wie werden wir die Aufgaben konkret lösen?

VIDEO ZUR SPRINT PLANUNG IN SCRUM

Die Sprint Planung im Video

Was die Gründer über die Sprint Planung sagen

Die Sprint Planung im Scrum Guide

Scrum Guide

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

ABLAUF DER SPRINT Planung

Input, Inhalt und Output des Sprint Plannings

Bevor wir uns im Folgenden die einzelnen Komponenten der Sprint Planung ansehen, starten wir hier mit einer Übersicht über das Scrum Event. Dazu nutze ich dieses einfache Schema mit dem Eingang, der Agenda, der Dauer und dem Output.

Thema

Inhalt

Input für die Sprint Planung

  • Der Product Owner bringt das priorisierte Product Backlog zur Sprint Planung.
  • Der Product Owner kann Gedanken & Ideen für das Sprint Ziel mitbringen
  • Erfahrungswerte der Velocity ggf. Verbesserungen aus der Retrospektive

Ablauf innerhalb der Sprint Planung

  • Die Product Backlog Items werden der Reihe (Priorisierung / Sortierung) nach vom Product Owner kurz vorgestellt.
  • Das Entwicklungsteam entscheidet, wie viele der vorgestellten Product Backlog Einträge in den Sprint gezogen werden.
  • Das Entwicklungsteam entscheidet wie die Product Backlog Items umgesetzt werden.
  • Ein Sprint Ziel wird festgelegt
  • Wenn nötig, kann die Definition of Done angepasst werden.

Output der Sprint Planung

  • Ein Sprint Backlog als Plan für das Entwicklungsteam für den Sprint.
  • Ein Sprint Ziel als Richtung für den Sprint
  • Ggf. eine geänderte Definition of Done

Dauer

  • Bei einem Monat Sprintlänge ist die Länge der Sprint Planung 8 Stunden, also einen Tag. Dabei werden Sprint Planung Teil 1 und Teil 2 zusammen betrachtet.
  • Diese Dauer ist recht gut getroffen und die Zeit wird (zu Beginn) auch benötigt.
  • Diese Dauer ist immer abhängig von dem, was Sie entwickeln und welche Product Backlog Items Sie im Product Backlog besitzen.

Anmerkungen

Die Sprint Planung wird meist in zwei Teile aufgeteilt.

Im ersten Teil ist der Product Owner sehr stark involviert und es wird lediglich aufgeführt wie viele Einträge das Team schaffen kann.

Im zweiten Teil der Sprint Planung ist das Entwicklungsteam unter sich und überlegt die konkrete Umsetzung.

Nicht immer ist das trennbar. Daher wird diese Unterscheidung nicht mehr im Scrum Guide aufgeführt, sondern von "Topics" gesprochen.

Es gibt Teams, die kein Sprint Planning 2 benötigen.

Was braucht es für eine Sprint Planung?

Eingang, Inhalt, Ergebnis - was Sie alles benötigen, um erfolgreich zu planen

Nachdem wir in der Übersicht über Input, Ablauf und Ergebnis des Sprint PlanningsInput, Ablauf und Ergebnis des Sprint Plannings den Überblick bekommen haben, werfen wir nun auf diesen ersten Teil einen genaueren Blick.

Im Folgenden finden Sie eine Übersicht über all das, was in einer Sprint Planung als Eingang zu zählen ist. Danach gehen wir auf den Ablauf ein, bei dem dieser Input relevant ist.

Product Backlog

Das Product Backlog enthält alle bekannten Anforderungen an das Produkt zum aktuellen Zeitpunkt. Es ist durch den Product Owner sortiert. Nur Einträge aus diesem Backlog können in die Sprint Planung gelangen, bei denen das Verständnis vorhanden ist, was zu tun ist. Das wird durch ein Refinement erreicht.

Definition of Done

Die Definition of Done (DoD) beschreibt, wann Arbeit als "fertig" beschrieben werden kann. Meistens findet diese Beschreibung zwischen dem Product Owner und dem Entwicklungsteam statt. Die DoD erlaubt den Teammitglieder zu schätzen, wieviele Product Backlog Items sie abschließen können. Organisationen können auch eine DoD vorgeben.

Velocity

Eine Velocity ist ein Maß für die umgesetzte Funktionalität. Zusammen mit der DoD kann so eine Planung für einen Sprint aufgestellt werden. Dabei wird immer empirisch gegen diese geprüft, wie viel Arbeit ein Team planen sollte. Fehlt diese Erfahrung, dann überplanen sich Teams häufig.

Verbesserungen

Wenn Sie in Ihrer Retrospektive etwas für die Sprint Planung zur Verbesserung angelegt haben, dann ist das ebenfalls ein Eingang. Diese Verbesserung kann vielfältig aussehen und ist dann ebenso im Sprint Backlog für den nächsten Sprint zu finden.

Inkrement

Abgesehen vom ersten Sprint besitzen Sie bereits Produktinkremente. Dieses sind wertvolle Erfahrungen und stellen damit Empirie dar. Diese wird bei der Sprint Planung berücksichtigt und gibt wertvolle Informationen über die Richtung des nächsten Sprints.

Wie kommen Sie zur guten konkreten Planung?

Ablauf - das tun Sie, um erfolgreich zu planen

Sie kennen nun den Input für Ihre Sprint Planung und wollen jetzt wissen, was genau in der Sprint Planning passiert? Dann sind Sie hier genau richtig. Aus Input, Ablauf und Ergebnis des Sprint Plannings haben wir nun schon ein paar Kenntnisse, die wir jetzt noch genauer konkretisieren. Häufig finden Sie drei verschiede Varianten, wie eine Sprint Planung durchgeführt wird. Die letzte Variante werde ich im Detail nicht besprechen, da sich diese aus den anderen beiden Varianten ergibt, in dem der zweite Teil wegfällt bzw. implizit gegeben ist.

  • Sie teilen die Sprint Planung in zwei separaten Teile auf und gehen diese dann nacheinander durch.
  • Sie nutzen die Sprint Planung ohne explizite separate Teile und trennen nicht.
  • Das "Wie" ist dem Team bekannt und wird nicht als expliziter Teil benötigt.

Zwei typische Varianten in der Sprint Planung

  • Vorstellung der Product Backlog Items durch den Product Owner. Der Product Onwer stellt die Einträge (nach seiner festgelegten Reihenfolge) kurz vor. Wenn das Backlog Refinement gut ist und die Teammitglieder alle Einträge verstanden haben, dann ist die Vorstellung sehr schnell abgeschlossen.
  • Das Entwicklungsteam sagt, wie viele Einträge es schaffen kann. Das Entwicklungsteam schätzt unter Einbeziehung der Velocity und der Definition of Done, wie viele dieser Einträge es schaffen kann. Dabei ist das Vorgehen meist so, dass das Product Backlog Item für Item durchgegangen wird. Das Team bestätigt die einzelnen Einträge - ob sie sie schaffen oder nicht mehr. Hat das Team das Gefühl, die Kapazität für diesen Sprint und die Velocity sind in etwa gleich, dann beendet es die Auswahl weiterer Product Backlog Items und tut das kund. Damit ist dann der erste Teil der Sprint Planung abgeschlossen.
  • Die Aufgaben werden durch das Entwicklungsteam konkretisiert. Der Product Owner zieht sich meistens etwas zurück, ist aber weiterhin für Fragen des Teams verfügbar. Die Teammitglieder setzen sich nun zusammen und überlegen, wie konkret sie nun die selektierten Product Backlog Items umsetzen wollen.
  • Das Sprint Ziel wird abgestimmt. Das Scrum Team definiert ein Sprint Ziel. Oft ist es ein Vorschlag des Product Owners und dann eine Diskussion mit dem Entwicklungsteam. 
  • Der Product Owner stellt das nächstwichtige Product Backlog Item vor.
  • Team sagt, ob es den Eintrag umsetzen kann. Das Team sagt dem Product Owner, ob sie das Product Backlog Item im Sprint umsetzen können. Ist es das Erste und es ausreichend genug im Refinement verfeinert worden, dann wird das sehr wahrscheinlich durch das Team im Sprint bearbeitet.
  • Das Team überlegt sich das konkrete WIE. Direkt nach der Vorstellung überlegt sich das Team, wie konkret es nun dieses Product Backlog Items umsetzen will. Es wird also nach der Selektion für den Sprint direkt verfeinert.
  • Definition des Sprint Ziels. Das Sprint Ziel muss nicht zwangsläufig am Ende festgelegt werden. 

Verständnis für Product Backlog Items für Coaches

Ich halte es in meinen Projekten als agiler Coach gerne zu Beginn immer so: Ich versuche mir ein Bild vom Product Backlog zu machen und möchte die Einträge dort verstehen können. Wenn ich mir später die konkreten Aufgaben des Entwicklungsteam ansehe, dann sollte ich diese nicht verstehen (grobe Faustregel).

Trennung Sprint Planning 1 und 2

Aus der Erfahrung ist die Trennung in zwei Teile immer damit begründet, dass der Product Owner sich mit dem WAS beschäftigt und nicht mit dem WIE, was Aufgabe des Entwicklungsteams ist. Oft wird eine Zeitersparnis dadurch angenommen, dass der Product Owner in der Zwischenzeit etwas anderes machen kann. Diese Annahme sollten Sie immer genauestens hinterfragen.

Was aus dem Sprint Planning heraus kommt!

Output - was Sie als Ergebnis bekommen

Nachdem wir in der Übersicht über Input, Ablauf und Ergebnis des Sprint Plannings den Überblick bekommen haben, werfen wir nun auf diesen letzten Teil einen genaueren Blick.

Wir kennen das, was in die Sprint Planung als Input hinein geht, haben gelernt, was innerhalb des Sprint Plannings passiert und schauen uns nun das Ergebnis an.

Sprint Backlog

Das Sprint Backlog ist das Artefakt des Entwicklungsteam und beschreibt die Planung und den Forecast für den kommenden Sprint.

Sprint Ziel

Das Sprint Ziel gibt die übergreifende Richtung für den Sprint vor, schärft den Fokus und hilft im Verständnis.

Definition of Done

Wenn die Definition of Done angepasst worden ist, dann ist die veränderte Definition of Done ebenfalls das Ergebnis der Sprint Planung.

Sprint Ziel

Das Sprint Ziel kann in der Sprint Planung zu jedem Zeitpunkt festgelegt werden. Wichtig ist es, dass es am Ende gemeinschaftlich abgestimmt ist und existiert. Wenn Sie kein Sprint Ziel erarbeiten können, dann werfen Sie einen Blick auf das Produkt oder den Teamschnitt.

Sprint Backlog und Vollständigkeit

Das Sprint Backlog muss am Ende der Sprint Planung nicht "vollständig" sein. Es ist wichtig, dass das Team einen konkreten Plan für die kommenden Tage hat und einen groben Plan für den Sprint. Es ist also durchaus möglich, dass nicht alle selektierten Product Backlog Items am Ende der Sprint Planung in Aufgaben herunter gebrochen sind.

Vor welchen Herausforderungen stehen Sie?

Typische Probleme in der Sprint Planung

1

Product Backlog Items unreif

Die Product Backlog Items sind unreif. Damit kann eine Planung nur bedingt stattfinden, weil das Entwicklungsteam kein Verständnis über die Arbeit hat.

2

Product Owner pusht

Der Product Owner schiebt Arbeit in den Sprint, obwohl das Entwicklungsteam diese Arbeit nicht schaffen kann.

3

Team schafft zu wenig

Das Team schafft keine oder zu wenig der vorgenommenen Aufgaben im Sprint.

4

Unklar, was Fertig bedeutet

Dem Entwicklungsteam ist nicht klar, wann etwas fertig ist, da die Definition of Done nicht oder nicht vollständig existiert.

5

Product Owner ohne Ziel

Der Product Owner hat kein Verständnis über ein Ziel in dem Sprint.

6

Velocity unklar

Das Entwicklungsteam kennt seine eigene Velocity nicht.

Sie haben Fragen? Hier gibt es Antworten!

FAQ zur Sprint Planung

Wir machen keine Sprint Planung 2, schlimm?

In der Regel werden Ihnen die Inhalte und Abhängigkeiten hinter einem Product Backlog Item (PBI) klar, wenn Sie die Aufgaben genauer betrachten. Deswegen gilt, für alle PBIs im Product Backlog: Was größer als die kleinste verwendete Einheit geschätzt wurde - schauen Sie es sich unbedingt genauer an. Erst wenn Sie darüber sprechen, dann finden Sie tatsächlich die Aufgaben, die Sie konkret tun müssen.

Muss ich Story Points in meiner Planung verwenden?

Story Points ist eine agile Praktik, die Ihnen helfen kann, zu schätzen. Sie müssen diese nicht zwingend verwenden. Der Scrum Guide sagt nur aus, dass die Product Backlog Items geschätzt sein müssen.

Kann ich die Sprint Planung verkürzen?

Für einen einmonatigen Sprint benötigt das Sprint Planning 8 Stunden. Diese Zeit skaliert mit der Länge des Sprints. Die Richtwerte spiegeln sehr gut den realen Bedarf wieder, den das Teams tatsächlich für die Planung benötigt.

Warum brauche ich fertige Product Backlog Items?

Wenn Sie keine fertigen Product Backlog Items für die Sprint Planung besitzen, dann dauert sie länger und das Ergebnis wird oft nicht wie erhofft sein.

BLOG liste

Die letzten Artikel

>