Sprint Planning: Team schätzt Aufwände

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

Das Sprint Planning ist eines der vier zentralen Events im agilen Framework Scrum. Im Planungstreffen bereitet ein Scrum-Team den Sprint vor und einigt sich auf ein gemeinsames Ziel und die zu erledigenden Aufgaben. Erfahren Sie in unserem Artikel, wie das Sprint Planning abläuft, welche Ziele es verfolgt und was im Anschluss passiert.

Was ist ein Sprint Planning?

Das Sprint Planning läutet in Scrum den Sprint ein. In dem Meeting kommt das ganze Team zusammen, um die Arbeiten des anstehenden Sprintzyklus zu planen. Am Ende stehen das Sprintziel und die zu erledigenden Aufgaben fest. Je nach Sprintlänge dauert das Planungstreffen zwischen zwei und acht Stunden und wird in der Regel in zwei Teilen abgehalten:

  1. Der erste Teil klärt das „Warum“ und „Was“ des Sprints: Das Team legt das Sprintziel fest und einigt sich darauf, was getan wird. Es wählt die Backlog Items aus dem Product Backlog aus, die im Sprint bearbeitet werden.
  2. Im zweiten Teil geht es um das „Wie“: Die Entwickler*innen besprechen die Details der einzelnen Backlog Items und brechen diese in Aufgaben herunter. Die einzelnen Aufgaben sind so geschnitten, dass sie in einem Arbeitstag oder weniger erledigt werden können.

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. Die Arbeit im Sprint wird über die vier Events Sprint Planning, Daily Standup, Sprint Review und Sprint Retrospective organisiert.

Das Sprint Planning initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt. Dieser resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt.

Scrum Guide

Am Sprint Planning nehmen der Product Owner, 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 im Sprint umgesetzt werden sollen. 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 im Sprint umgesetzt werden. Die vereinbarten Arbeiten wandern vom Product Backlog in den Sprint Backlog und werden so zum Arbeitspaket für den Sprint.

Wer nimmt am Sprint Planning teil?

Kurze Antwort: Das gesamte Scrum-Team (Product Owner, Scrum Master, Entwickler*innen). Organisiert wird das Meeting vom Product Owner. Das Sprint Planning ist ein 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.

Ausbildung zum Agile Coach

Treiben Sie den Kulturwandel in Ihrem Unternehmen voran. In unserer berufsbegleitenden Ausbildung erhalten Sie alle Werkzeuge, die es braucht, um die Rolle des Agile Coach einzunehmen.

Erfahren Sie mehr zur Ausbildung
Agile Coaches sorgen für mehr Kommunikation zwischen Interessensgruppen

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.

Beispiele für ein Sprintziel

Ein Beispiel: Das Scrum-Team entwickelt eine neue Webseite (Produkt) für seine Organisation. Während eines Sprints erstellt das Team bestimmte Bestandteile oder Features des neuen Internetauftritts. Ein mögliches Sprintziel wäre die Gestaltung und Veröffentlichung der Startseite oder die Implementierung eines Kontaktformulars.

Ein weiteres Ziel des Sprint Plannings ist der Aufbau und die Pflege des Sprint Backlogs. Hier sammelt das Team alle Backlog Items, die während des Sprints umgesetzt werden, 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 wird also keine hundertprozentige Auslastung geplant. 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.

Verkehrsstau
Was passiert, wenn Straßen zu 100 % ausgelastet sind? Nichts geht mehr voran. (Quelle: Wolfram Däumel)
Was passiert, wenn Straßen zu 100 % ausgelastet sind? Nichts geht mehr voran. (Quelle: Wolfram Däumel)

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 können auch neue User Stories ins Backlog aufgenommen, einzelne Stories zusammengefasst oder Aufwandsschätzungen getätigt werden.

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 in den Sprints gewonnen werden, 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.

Managen Sie Ihre Projekte mit Scrum

Lernen Sie in unseren “Agile Atoms”, wie Sie das Scrum-Framework auch in Ihrem Unternehmen implementieren. Passen Sie unser modulares Trainingsprogramm individuell auf Ihre Bedürfnisse an.

Zu den Agile Atoms
Teammitglieder von Me & Company in einem internen Workshop

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.

Agile Performance Management mit Sprint Velocity
Beispiel für ein Velocity-Chart, in dem ein Team die geschätzten und tatsächlich erreichten Story Points der Sprints dokumentiert.
Beispiel für ein Velocity-Chart, in dem ein Team die geschätzten und tatsächlich erreichten Story Points der Sprints dokumentiert.

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 Aufwandschä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.

Der Product Owner schlägt vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprint‐Ziel zu definieren, das verdeutlicht, warum der Sprint für die Stakeholder wertvoll ist.

Scrum Guide

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.

Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event in der Regel kürzer.

Scrum Guide

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.

Ausbildung zum Agile Coach

In unserem Train-the-Trainer Programm werden Sie in 10 Monaten zum Agile Coach. In 8 Modulen lernen Sie die 8 Aufgabenfelder der Rolle in einer praxisnahen Ausbildung kennen.

Erfahren Sie mehr zur Ausbildung
Vanessa Bern von Me & Company visualisiert Arbeit mit Post Its
NACH OBEN