Sprint Planning: Teilnehmer, Ziel und Ablauf des Scrum-Events

In welchen Rahmen findet das Sprint Planning statt?

Scrum arbeitet in kurzen Sprints, die in der Regel zwei, maximal vier Wochen dauern. Innerhalb eines Sprints entwickelt das Scrum-Team ein Produktbestandteil (Inkrement) und liefert diesen aus. Das Team organisiert die Arbeit im Sprint über die vier Events Sprint Planning, Daily Standup, Sprint Review und Sprint Retrospective.

Am Sprint Planning nehmen der Product Owner, der Scrum Master und die Entwickler*innen des Scrum-Teams teil. Laut Scrum Guide ist es auch möglich, andere Stakeholder aus der Organisation als Berater*innen einzuladen. In der Praxis findet dies jedoch nur selten statt und der Product Owner hat mit den Partnern bereits vor dem Meeting über die Anforderungen gesprochen.

Was passiert im Sprint Planning?

Im Sprint Planning definiert das Scrum-Team das Sprint-Ziel und legt gemeinsam die Arbeit des anstehenden Sprints fest. Das Planungstreffen klärt im Wesentlichen drei Fragen:

1. Prioritäten: Welche Arbeitsergebnisse liefern unseren Kunden aktuell den größten Wert?
2. Ergebnisqualität: Wie liefern wir eine passende Balance zwischen Aufwand und Mehrwert?
3. Aufwand: Wie viel Arbeitzeit benötigt die angedachte Umsetzung?

Grob zusammengefasst: Der Product Owner bereitet ein Sprintziel vor und definiert die Backlog Items (z. B. User Stories oder Epics) aus dem Product Backlog, die das Team im Sprint umsetzen soll. Im Sprint Planning stellt er dies vor und diskutiert mit dem Team die einzelnen Arbeiten. Oft schätzt das Entwicklerteam den Aufwand für die jeweiligen Backlog Items und entscheidet, welche es im Sprint umsetzt. Die vereinbarten Arbeiten wandern vom Product Backlog in den Sprint Backlog und bilden so das Arbeitspaket für den Sprint.

Wer nimmt am Sprint Planning teil?

Kurze Antwort: Das gesamte Scrum-Team (Product Owner, Scrum Master, Entwickler*innen). Der Product Owner organisiert das Regeltreffen, das gewöhnlich zu Beginn des Sprints stattfindet. Viele Teams haben einen festen Zeitraum für ihren Sprint festgelegt (1 bis 4 Wochen), sodass der Termin für das Sprint Planning gut im Voraus geplant und als Regeltermin in den Kalendern des Teams vermerkt werden kann.

Der Scrum Master (in manchen Teams auch ein Agile Coach) sorgt dafür, dass das Treffen stattfindet, stellt sicher, dass der vereinbarte Ablauf eingehalten wird und die Teilnehmer*innen ein gemeinsames Verständnis über das Sprint-Ziel entwickeln. Als Berater*innen können unter Umständen Stakeholder aus dem Unternehmen dazukommen, sofern sie eine wichtige Perspektive oder hilfreiches Wissen mitbringen. In der Regel bleibt das Scrum-Team im Sprint Planning unter sich und hat alle notwendigen Informationen und Anforderungen bereits zusammengestellt.

Ziele des Planungstreffens

Im Sprint Planning einigen sich Product Owner und Entwickler*innen auf ein gemeinsames Sprintziel. Das Sprintziel beschreibt das Ergebnis bzw. den Outcome des Sprints, den das Team erarbeitet. Es ist ein kurzfristiger Meilenstein auf dem Weg zum finalen Produkt. Am Ende des Sprints steht ein auslieferbares Produkt-Inkrement, das bereits einen Kundennutzen bietet.

Ein weiteres Ziel des Sprint Plannings ist der Aufbau und die Pflege des Sprint Backlogs. Hier sammelt das Team alle Backlog Items, die es während des Sprints umsetzt, um das Sprintziel zu erfüllen. Wichtig: Diese Backlog Items oder Aufträge sind nicht als Aufgaben formuliert, sondern beschreiben ein erwartetes Arbeitsergebnis sowie die Anforderungen (Requirements), die an dieses gestellt werden. In unserem Beispiel wäre ein solches Item etwa die Texte für die Produktübersicht auf der Startseite oder die Oberfläche für das Kontaktformular.

Hierbei achtet das Team gleichzeitig darauf, nicht zu viel Arbeit in den Sprint Backlog zu packen. Unvorhergesehenes kann immer passieren und es ist möglich, dass das Team während des Sprints Fehler beheben oder kleinere Ausbesserungsarbeiten erledigen muss. Es plant also keine hundertprozentige Auslastung. Das ist auch aus einem anderen Grund sinnvoll: Bei 100 Prozent Auslastung sinkt die Produktivität und Innovationskraft der Mitarbeitenden: Wer seine ganze Arbeitszeit mit Aufgaben zugestopft ist, hat keine Chance mehr auf Änderungen zu reagieren und weiter zu denken.

Was ist der Unterschied zwischen einem Backlog Refinement und dem Sprint Planning?

Im Backlog Refinement (auch Backlog Grooming genannt) bereiten Product Owner und Entwickler*innen die Items des Product Backlogs für das Sprint Planning vor. Hier besprechen sie die am höchsten priorisierten Einträge und arbeiten die Anforderungen weiter aus. So werden einzelne Items mit neuen Informationen angereichert, Akzeptanzkriterien formuliert oder die Einträge neu priorisiert, falls sich die Situation geändert hat. Zudem kann das Team auch neue User Stories ins Backlog aufnehmen, einzelne Stories zusammenfassen oder Aufwandsschätzungen tätigen.

Als Vorbereitung für das Sprint Planning sollte das Backlog Refinement regelmäßig stattfinden. Ein gut gepflegtes Backlog, das alle aktuellen Informationen berücksichtigt, macht das Sprint Planning deutlich effizienter. Wie oft und wann das Backlog Refinement stattfindet, entscheidet jedes Team für sich. Ob einmal die Woche oder einmal während des laufenden Sprints – das hängt ganz von der jeweiligen Situation und Informationslage ab. Wir empfehlen ein regelmäßiges Backlog Refinement alle zwei bis drei Sprints, um einerseits das Sprint Planning vorzubereiten und andererseits das „große Ganze“ nicht aus den Augen zu verlieren.

Product Backlog vs. Sprint Backlog

Im Product Backlog sammelt das Scrum-Team alle User Stories, Epics und Aufgaben, die bei der Erstellung des finalen Produkts erforderlich sind. Der Product Owner priorisiert die Backlog-Einträge, sodass die Stories mit dem höchsten Kundennutzen oben stehen. Die Priorisierung erfolgt dabei meist gemeinsam mit den Entwickler*innen.

Das Product Backlog ist aber keine geschlossene Liste, die am Anfang der Entwicklungsphase erstellt und dann abgearbeitet wird. Im Verlauf wächst und verändert sich diese Liste ständig. Einerseits durch die Erkenntnisse, die das Team in den Sprints gewinnt, andererseits durch neue Anforderungen, die entstehen. Aus diesem Grund ist auch ein regelmäßiges Backlog Refinement nötig, um diese Veränderungen zu koordinieren.

Im oben genannten Beispiel besteht das Product Backlog aus allen Stories, die zur Erstellung der Webseite nötig sind wie z. B. Startseite, Kontaktformular oder Produktseiten. Wenn das Marketing plötzlich feststellt, dass es unbedingt noch einen Blog auf der Webseite benötigt, kann dies auch in das Backlog aufgenommen und entsprechend priorisiert werden.

Im Gegensatz zum Product Backlog enthält das Sprint Backlog alle für den aktuellen Sprint ausgewählten Backlog-Einträge und ein übergeordnetes Sprint-Ziel.

Vorbereitung des Sprint Plannings

Eine der wichtigsten Vorbereitungen für das Sprint Planning ist ein regelmäßiges Backlog Refinement, in dem die wichtigsten Einträge auf den aktuellen Stand gebracht werden. Für ein effektives Meeting sollte der Product Owner (PO) zudem folgende Dinge vorbereiten:

• Idealerweise hat er die Erkenntnisse der letzten Sprint Review und Retrospektive sowie Stakeholder-Feedback in das Backlog aufgenommen.
• Vordefinition Sprintziel mit dazugehörigen priorisierten Backlog Items, die im Planning diskutiert werden können
• Übersicht der bereits erledigten Arbeiten

Ebenfalls hilfreich bei der Planung ist eine Einschätzung der Teamkapazität für den nächsten Sprint, die in der Praxis häufig der Scrum Master vornimmt. Hierbei berücksichtigt er die durchschnittliche Leistungsfähigkeit des Teams (Team-Velocity) der letzten Sprints und bezieht auch Abwesenheiten einzelner Teammitglieder (Urlaub, Fortbildung o. ä.) ein.

Sprint Planning: Ablauf und Dauer des Planungstreffens

Die Planung eines Scrum-Sprints verläuft meistens nach folgender Agenda:

1. Der Product Owner (PO) stellt sein vordefiniertes Sprintziel vor und teilt seine Vorstellung, wie der Wert des Produkts im anstehenden Sprint gesteigert werden soll. Das finale Sprintziel legen Product Owner und Entwickler*innen gemeinsam fest.
2. Der PO benennt die (priorisierten) Einträge aus dem Product Backlog, die zum Erreichen des Ziels umgesetzt werden sollen.
3. Das Team schätzt den Aufwand für die einzelnen Einträge ein – sofern dies noch nicht vorher geschehen ist (z. B. im Backlog Refinement). Gegebenenfalls verfeinert das Team einzelne Einträge oder Inhalte (Bsp. Akzeptanzkriterien).
4. Das Team wählt die Backlog Items aus, die es bis zum Ende des Sprints liefern wird. An dieser Stelle bespricht der Product Owner mit den Entwickler*innen die zu erledigenden Aufgaben auf Basis von Kundenwert und Aufwand. Reichen die ausgewählten Einträge aus, um das Sprintziel zu erreichen und Wert für den Kunden zu erzeugen? Am Ende entscheiden die Entwickler*innen eigenständig, wie viel Arbeit sie im Sprint übernehmen. Wichtig: Diese Auswahl ist keine Verpflichtung gegenüber Product Owner und Stakeholdern, sondern eine Vorhersage basierend auf der Aufwandsschätzung und der durchschnittlichen Team-Velocity.
5. Im Anschluss setzen sich die Entwickler*innen zusammen, um die ausgewählten Backlog Items in kleinere Aufgaben herunterzubrechen. Diese Arbeitspakete sind bestenfalls so geschnitten, dass sie an einem Tag oder weniger abgeschlossen werden können.
6. Das gemeinschaftlich abgestimmte Sprint-Ziel, die zu bearbeitenden Backlog-Items und der Plan, wie diese bearbeitet werden, bilden das Sprint-Backlog.
7. Viele Teams visualisieren den Sprint Backlog und die zu erledigenden Aufgaben in einem Scrum-Board. Jedes Team hat ein eigenes Board und nutzt unterschiedliche Spalten, um den Fortschritt im Sprint zu dokumentieren. Im Kern dürften die wichtigsten Spalten aller Boards aber die folgenden drei sein: „To Do“, „Doing“, „Done“.

Die zwei Phasen des Sprint Plannings

In der Praxis splitten viele Scrum-Teams das Sprint Planning in zwei Phasen auf: Im ersten Teil finden die ersten vier der oben beschriebenen Agendapunkte statt. Product Owner und Team klären die Fragen: „Warum ist dieser Sprint wertvoll?“ und „Was wird in diesem Sprint umgesetzt?“ Den zweiten Teil bestreiten die Entwickler ohne den PO und beschäftigen sich damit, wie sie die ausgewählten Arbeiten erledigen.

Wie lange dauert das Sprint Planning?

Die Dauer des Sprint Plannings ist abhängig von der Länge des Sprints: Der Scrum Guide begrenzt die Länge des Meetings bei einem einmonatigen Sprint auf einen Arbeitstag bzw. acht Stunden. Ist der Sprint kürzer, verkürzt sich dementsprechend auch die Dauer des Plannings: Als Faustregel kann man pro Woche Sprint zwei Stunden Planungstreffen ansetzen.

Die Timebox sollte nicht überschritten werden. Oft benötigen Teams nicht die gesamte Zeit. Ist vor Ablauf der Zeit das Sprintziel definiert und das Sprint Backlog gefüllt, endet auch das Sprint Planning. Gerade erfahrene Teams, die schon viele Sprints gemeinsam absolviert haben und Kapazitäten und Aufwände routiniert einschätzen können, beschließen das Sprint Planning häufig vor der Zeit.

Aufwandschätzung im Team

Wie viel Arbeit kann das Team im Sprint erledigen? Das ist eine der zentralen Fragen, die die Entwickler*innen im Sprint Planning beantworten müssen. Um eine Voraussage treffen zu können, geben sie eine Schätzung ab. Dies kann durchaus eine große Herausforderung darstellen, da das Team hier mit vielen unbekannten Variablen rechnet. Über die Zeit und die Erfahrung, die es in den abgeschlossenen Sprints gewinnt, wird das Team in der Schätzung aber immer sicherer.

Wichtige Rahmenbedingungen für die Schätzung sind die Erkenntnisse über die Leistungen der vorherigen Sprints und die Team-Kapazität für den kommenden Sprint. Auf Basis dieser Überlegungen schätzt das Team die Arbeitsmenge (Velocity) ein, die es im Sprint bewältigen kann.

Schätzmethoden: Story Points, T-Shirt-Größen oder Planning Poker

Viele Scrum-Teams, die an langfristigen Projekten arbeiten, schätzen ihre Velocity in Story Points. Story Points sind eine abstrakte Einheit, mit der das Team den Aufwand eines Backlog Items misst. Dies erfolgt anhand dreier Kriterien:

• Menge an Arbeit: Wie viele Teilaufgaben müssen zur Erfüllung der User Story erledigt werden?
• Risiken und Ungewissheit: Sind alle Anforderungen klar oder könnte es zu unerwarteten Verzögerungen und Änderungen kommen?
• Komplexität der Story: Sind einzelne Teilaufgaben miteinander verknüpft, sodass die Komplexität der Story steigt? Und gibt es Abhängigkeiten, die außerhalb des Team liegen?

Im Sprint Planning gibt das Team zunächst eine Schätzung ab, wie viele Story Points es im Sprint insgesamt erreichen kann. Diese Einschätzung basiert auf der durchschnittlich erreichten Story-Point-Anzahl der vergangenen Sprints. Anhand dieser Einschätzung bewerten die Entwickler*innen die einzelnen Backlog Items und wählen aus, wie viele sie davon ins Sprint Backlog aufnehmen.

Bei kleineren Teams oder Projekten eignet sich auch die Zeitschätzung: Bei dieser Methode bewertet das Team die Aufgaben anhand der Zeit, die es für die Bearbeitung benötigt. Weitere Techniken sind beispielsweise die Aufwandschätzung anhand von T-Shirt-Größen oder die Planning-Poker-Methode.

Wie geht es nach dem Sprint Planning weiter? 

Das Sprint Planning gibt den Auftakt zum Sprint. Während des Sprints arbeitet das Team an dem vereinbarten Arbeitspaket. Ein Scrum Board visualisiert den Fortschritt und aktuellen Stand, den das Team im Daily Standup, dem täglichen Fortschrittsmeeting, bespricht. Hier diskutieren Entwickler*innen, Product Owner und Scrum Master auch über aktuelle Probleme und Hindernisse, die die Arbeit behindern. Wann ein Item aus dem Sprint Backlog fertiggestellt ist, bewertet das Team anhand seiner gemeinsam entwickelten Definition of Done.

Am Ende des Sprintzyklus präsentiert das Scrum-Team in der Sprint Review die Ergebnisse und das auslieferbare Produkt-Inkrement. Hier zeigt sich, wie gut die Schätzung des Teams war und wie viele Story Points es realisiert bzw. wie viele der Backlog Items es umgesetzt hat. Zum Abschluss des Sprints hält das Team eine Sprint Retrospective ab, in der alle Mitglieder die Erkenntnisse des vergangenen Sprints reflektieren und Verbesserung in der teaminternen Zusammenarbeit diskutieren.

Gestalten Sie Ihr eigenes Sprint Planning

Sie möchten Ihre Projekte zukünftig mit Scrum managen? Wir unterstützen Sie gerne dabei. Die Agile Coaches von Me & Company begleiten Ihre Teams bei der Einführung von Scrum und im Alltag. Wir übernehmen gerne auch Product Ownership und führen Ideen in einem agilen Team zu einem erfolgreichen Produkt.