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: Wieviel 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.

Die Keyfacts der Sprint Planung

  • Erstes Event im Sprint
  • Product Owner und Entwicklungsteam
  • Ziel für den nächsten Sprint festlegen
  • Wieviel werden wir schaffen?
  • Wie werden wir es schaffen?

Übersicht über diesen Artikel

In diesem Artikel zeige ich Ihnen zunächst, was der Scrum Guide über die Sprint Planung aussagt. Diese Informationen habe ich Ihnen folgend übersichtlich in einer Input, Ablauf und Ergebnis Übersicht zusammengefasst. Danach schauen wir uns die Details dazu an, bevor wir zu typischen Problemen kommen. In entsprechenden Boxen finden Sie Tipps & Tricks.

Die Sprint Planung im Detail

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

Input, Ablauf und Ergebnis

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.

Agenda

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, wieviele 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

Oft wird die Sprint Planung in zwei Teile aufgeteilt, in dem ersten Teil sagt das lediglich wieviele Einträge es schaffen kann. Dabei ist der Product Owner sehr stark involviert. In dem zweiten Teil der Sprint Planung ist das Entwicklungsteam dann unter sich, da es sich konkret die Umsetzung überlegt. 

Nicht immer ist das trennbar, deswegen gibt es diese Unterscheidung auch nicht mehr im Scrum Guide, sondern es wird nur noch von "Topics" gesprochen. Es gibt Teams, die kein Sprint Planning 2 benötigen.

Input - was Sie alles benötigen, um erfolgreich zu starten

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

Im Folgenden finden Sie eine Übersicht über alles 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 in diesem Backlog können in die Sprint Planung gelangen, bei denen das Verständnis vorhanden ist, was zutun ist. Das wird durch ein Refinement erreicht.

Definition of Done

Die Definition of Done (DoD) beschreibt, wann Arbeit fertig ist. Meistens findet diese Beschreibung zwischen Product Owner und 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, wieviel 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.

Hauptprobleme in der Sprint Planung

Ohne auf eine konkrete Implementierung zu schauen, können Sie immer die folgenden Punkte im Kopf behalten, wenn eine Sprint Planung nicht gut läuft:

  • dass die Product Backlog Items nicht reif sind
  • es fehlen die richtigen Teammitglieder
  • die Velocity und Kapazität des Teams sind nicht klar

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.
Teil 1, dann Teil 2
  • 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, wieviele 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 Product Backlog Item für Item durchgegangen wird und zu jedem Eintrag das Team sagt, ob sie es schaffen oder eben nicht mehr. Hat das Team das Gefühl, die Kapazität für diesen Sprint und die Velocity sind in etwas 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. 
Teil 1 & Teil 2 gemischt
  • Der Product Owner stellt das nächst wichtigste 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 umsetzten 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. Je höher die Anzahl der bereits im Sprint befindlichen Product Backlog Items, desto geringer die Wahrscheinlichkeit, dass das nächste Product Backlog Item ebenfalls ausgewählt wird. 
  • 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.

Hilfe zu Beginn

Wenn Teams aus einem nicht agilen Umfeld starten, kann es hilfreich sein, mit einer Struktur zu führen. Probieren Sie dann einfach eine Variante der Sprint Planung aus. Tendenziell wird der sequenzielle Ansatz für die Teammitglieder

Output - was Sie als Ergebnis bekommen

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

A text section like this is great for describing your product in detail and telling a story about the benefits it will bring to a customer. It is also a good idea to address potential objections that are on your reader's mind (e.g. "will this really work for me?") in text sections like this.

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 in der auf Aufgaben bereits am Ende der Sprint Planung herunter gebrochen sind.

Typische Probleme in der Sprint Planung

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.

Product Owner pusht

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

Team schafft zu wenig

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

Unklar, was fertig bedeutet

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

Product Owner ohne Ziel

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

Velocity unklar

Das Entwicklungsteam kennt seine eigene Velocity nicht.


Scrum und die Sprint Planung in meinem Newsletter für Sie - tragen auch Sie sich gleich mit ein!

Sebastian Schneider ScrumKurs24

Lassen Sie uns gerne über Ihren Start mit Scrum sprechen. Mit meinen Erfahrungen aus über 14 Jahren unterstütze ich auch Sie zielgerecht.

Sie können schnell und einfach einen Termin für Scrum mit mir online vereinbaren. Wenn Sie Scrum in Augsburg suchen, können wir uns auch gerne persönlich treffen und ich besuche Sie direkt im Unternehmen. Ansonsten stehe ich gerne für ein Telefonat bereit.

Sebastian Schneider

© 2019, Wertikalwerk GmbH

>