Sprint-Planung: Was ist das & wie macht man es?
Bist du bereit, das Beste aus der Sprint-Planung herauszuholen? Als agiler Projektmanager oder Product Owner liegt es an dir, dafür zu sorgen, dass alle auf dem gleichen Stand sind und Ergebnisse geliefert werden.
Es ist also an der Zeit, das Chaos zu entwirren und die Erfolgskriterien mit diesem ultimativen Leitfaden zu erfüllen, der deine Sprint-Planung so gut organisiert, dass du Marie Kondo Konkurrenz machen könntest! Auch wenn ein gutes agiles Projektmanagement-Tool sehr hilfreich sein kann, geht dennoch nichts über menschlichen Verstand und Teamwork, um einen erfolgreichen Sprint-Plan zu erstellen.
Daher führe ich dich in diesem umfassenden Leitfaden durch alles, was du für die Planung erfolgreicher Sprints benötigst – einschließlich der Festlegung eines Sprint-Ziels, der Vorbereitung auf das Sprint-Planungsmeeting, der Zusammenstellung der Meeting-Agenda und weiteren Best Practices.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Was ist Sprint-Planung?
Sprint-Planung ist die Anfangsphase eines agilen Entwicklungszyklus und Teil der agilen Projektplanung. In diesem Meeting kommt das gesamte Team zu einer Sprint-Planungsbesprechung zusammen, um die im Sprint zu erledigende Arbeit zu definieren und einen Plan zu erstellen, um diese Ziele zu erreichen.
In der Regel ist das Sprint-Planungsmeeting in zwei Teile gegliedert:
- Das „Warum“ und „Was“ des Sprints: Das Team formuliert das Ziel des Sprints und einigt sich auf den zu erledigenden Inhalt. Aus dem Product Backlog werden jene Backlog Items ausgewählt, die im Sprint bearbeitet werden sollen. Projektplanungs-Tools mit Sprint-Planungsfunktionen helfen dabei, Backlog-Items zu organisieren und zu priorisieren, sodass das Team fokussiert und abgestimmt auf die Sprint-Ziele bleibt.
- Das „Wie“ des Sprints: Die Entwickler besprechen die Details der einzelnen Backlog-Items und zerlegen sie in Aufgaben. Jede Aufgabe ist so zugeschnitten, dass sie innerhalb eines Arbeitstags oder weniger erledigt werden kann und mit einem Task-Management-Tool nachverfolgt werden kann.
Abhängig von der Länge des Sprints dauert das Planungsmeeting zwischen zwei und acht Stunden. Es sollte im Verhältnis zur Sprint-Länge terminiert werden (z. B. maximal 4 Stunden Meeting bei einem zweiwöchigen Sprint).
Am Ende des Meetings sollten das Sprint-Ziel sowie die zu erledigenden Aufgaben feststehen und der Sprint offiziell gestartet sein.
Warum ist die Sprint-Planung wichtig?
Die Sprint-Planung ist wichtig, weil sie eine klare Richtung für den kommenden Sprint des Teams vorgibt. Wenn sie gut durchgeführt wird, kann eine Sprint-Planungssitzung:
- Ein gemeinsames und klares Verständnis der Projektziele und -vorgaben schaffen
- Teams ermöglichen, Aufgaben für den kommenden Sprint zu priorisieren und auszuwählen
- Eine effektive Ressourcenzuteilung und Zeitmanagement fördern
- Zusammenarbeit und Kommunikation unter den Teammitgliedern stärken
Insgesamt ist die Sprint-Planung ein wichtiger Vorbereitungsschritt im agilen Projektmanagement. Sie bildet die Grundlage für einen gut organisierten und effizienten Sprint, sodass Teams innerhalb des festgelegten Zeitrahmens hochwertige Ergebnisse liefern können.
Wer nimmt an der Sprint-Planung teil?
Kurz gesagt: Das gesamte Scrum-Team sollte an der Sprint-Planung teilnehmen und zu Beginn jedes Sprints das Scrum-Event besuchen. Zu diesen Teammitgliedern gehören:
- Der Product Owner: Liefert Einblicke in die Produktvision, klärt Anforderungen und legt die Prioritäten der Backlog-Items fest, die im Sprint bearbeitet werden sollen.
- Der Scrum Master (bei einigen Teams auch Agile Coach genannt und nicht mit einem Projektmanager zu verwechseln): Moderiert die Besprechung, stellt sicher, dass der vereinbarte Arbeitsablauf eingehalten wird und dass alle Teilnehmenden ein gemeinsames Verständnis des Sprint-Ziels entwickeln.
- Die Entwickler: Bringen technisches Fachwissen und Einschätzungen zur Umsetzbarkeit und zum Aufwand für die Implementierung von User Stories ein.
Manchmal nehmen auch Stakeholder aus dem Unternehmen als Berater teil, wenn sie eine wichtige Perspektive oder nützliches Wissen einbringen können.
Wie bereite ich das Sprint-Planungsmeeting vor?
Für ein effektives Meeting sollte der Product Owner (PO) folgende Dinge vorbereiten:
- Die Ergebnisse des letzten Sprint Reviews und Sprint Retrospective sowie Stakeholder-Feedback im Backlog.
- Einen Überblick über die bereits geleistete Arbeit.
Zusätzlich sollte sich der Product Owner auf das Sprint-Planungs-Meeting vorbereiten, indem er mehrere Prozesse durchführt, die ich im Folgenden näher erläutern werde. Dazu gehören:
- Vorabdefinition des Sprint-Ziels mit zugehörigen, priorisierten Backlog-Einträgen, die in der Planung besprochen werden können.
- Regelmäßige Verfeinerung des Backlogs, bei der die wichtigsten Einträge aktualisiert werden.
- Bewertung der Team-Velocity und -Kapazität für den nächsten Sprint.
Diese drei Aktivitäten werde ich im Folgenden ausführlich beschreiben.
Was ist ein Sprint-Ziel?
Während des Sprint-Planungs treffen sich der Product Owner und die Entwickler und einigen sich auf ein konkretes Sprint-Ziel. Das Sprint-Ziel beschreibt das Ergebnis oder den Nutzen des neuen Sprints, an dem das Team arbeitet. Es ist ein kurzfristiger Meilenstein auf dem Weg zum finalen Produkt.
Das Ziel ist, dass am Ende des Sprints ein lieferbares Produktinkrement vorhanden ist, das den Kunden bereits einen Nutzen bietet.
Was ist ein Backlog?
Wenn Sie Product Owner sind, haben Sie den Begriff "Backlog" wahrscheinlich schon unzählige Male gehört. Aber was genau ist das? Natürlich, auf einer grundlegenden Ebene wissen wir alle, was es ist – eine Liste von Aufgaben oder Funktionen, die erledigt werden müssen.
Wenn es jedoch um die Feinheiten geht, wie etwa den Unterschied zwischen Product Backlog und Sprint Backlog, wird es schnell kompliziert. Also machen Sie sich bereit – wir tauchen gemeinsam tiefer ein!
Product Backlog vs Sprint Backlog
Das Scrum-Team sammelt alle User Storys, Epics und Aufgaben, die zur Erstellung des finalen Produkts benötigt werden, im Product Backlog. Der Product Owner priorisiert die Backlog-Einträge so, dass die Storys mit dem höchsten Kundennutzen ganz oben stehen. Diese Priorisierung erfolgt in der Regel gemeinsam mit den Entwicklern.
Das Product Backlog ist jedoch keine endgültige Liste, die zu Beginn der Entwicklungsphase erstellt und dann abgearbeitet wird. Nein, diese Liste wächst und ändert sich ständig im Laufe der Zeit.
Es erweitert sich sowohl durch die in den Sprints gewonnenen Erkenntnisse als auch durch neue Anforderungen, die im weiteren Verlauf entstehen. Daher ist eine regelmäßige Verfeinerung des Backlogs notwendig, um diese Veränderungen zu berücksichtigen.
Zum Beispiel: Angenommen, das Product Backlog umfasst alle Storys, die für die Erstellung einer Website notwendig sind, wie z. B. die Startseite, das Kontaktformular und Produktseiten. Wenn das Marketing-Team plötzlich feststellt, dass unbedingt ein Blog-Bereich auf der Website benötigt wird, kann dies ins Backlog aufgenommen und entsprechend priorisiert werden.
Im Vergleich zum Product Backlog enthält das Sprint Backlog nur die für den aktuellen Sprint ausgewählten Backlog-Einträge und ein übergeordnetes Sprint-Ziel.
Wie schätzt man Backlog-Einträge?
Wie viel Arbeit kann ein Team im Sprint erledigen? Das ist eine der zentralen Fragen, die die Entwickler während des Sprint-Plannings beantworten müssen. Um eine Prognose abgeben zu können, führen sie eine Schätzung durch.
Das kann durchaus herausfordernd sein, da das Team mit vielen unbekannten Variablen konfrontiert ist. Mit zunehmender Erfahrung und den aus abgeschlossenen Sprints gewonnenen Erkenntnissen wird das Team aber immer besser in seinen Schätzungen.
Wie berechnet man Velocity und Kapazität eines Teams?
Bevor mit der Schätzung begonnen werden kann, ist es wichtig, die durchschnittliche Leistung der vorherigen Sprints (Velocity) und die verfügbare Teamkapazität für den kommenden Sprint zu kennen, die eventuell durch Schulungen, Urlaub usw. verringert wird.
Auf Basis dieser Überlegungen schätzt das Team die Arbeitsmenge (Velocity), die im Sprint bewältigt werden kann, bewertet anschließend die einzelnen Backlog-Einträge und wählt aus, wie viele davon in das Sprint Backlog aufgenommen werden.
Angenommen, die durchschnittliche Velocity lag in den letzten Sprints (Zwei-Wochen-Rhythmus) bei 40 Story Points und es wird keine wesentliche Reduzierung der Verfügbarkeit von Teammitgliedern erwartet, dann plant das Team den Sprint so, dass diese Velocity beibehalten wird (d. h., die ausgewählten Backlog-Einträge für den kommenden Sprint füllen ungefähr 40 Story Points).
Während die durchschnittliche Zeit zur Erledigung einer Aufgabe in der Regel mit einem guten Zeiterfassungs-Tool verfolgt werden kann, stehen auch mehrere andere Schätzmethoden zur Verfügung, um agile Kapazitätsplanung durchzuführen und die Velocity Ihres Teams zu bestimmen.
Schätzmethoden: Ein kurzer Überblick
Möchten Sie das Schätzen besser verstehen? Es gibt verschiedene Methoden und Einflussgrößen, weshalb das Thema oft einschüchternd erscheint – aber keine Sorge! Mit Grundkenntnissen sind Sie schon bald in der Lage, Ihr Backlog korrekt zu schätzen.
Story Points
Viele Agile-Teams, die an langfristigen Projekten arbeiten, schätzen ihre Velocity in Story Points.
Story Points sind eine abstrakte Einheit, die das Team verwendet, um den Aufwand zur Umsetzung eines Backlog-Elements zu schätzen. Diese Einschätzung basiert auf drei Kriterien:
- Arbeitsaufwand: Wie viele Unteraufgaben müssen erledigt werden, um die User Story abzuschließen?
- Risiken und Unsicherheiten: Sind alle Anforderungen klar oder könnte es unerwartete Verzögerungen und Änderungen geben?
- Komplexität der Story: Sind einzelne Unteraufgaben miteinander verknüpft, sodass die Komplexität der Story steigt? Und gibt es Abhängigkeiten außerhalb des Teams?
Die Fibonacci-Folge & Primzahlen
Agile Planung mithilfe der Fibonacci-Folge und von Primzahlen hilft Teams, Prognosen zu erstellen, die nicht nur auf optimistischen Bauchgefühlen beruhen, sondern sich auf Prinzipien der Zahlenlogik stützen.
Wenn eine User Story viele Variablen hat und im Umfang komplex oder groß angelegt ist, bedeutet die Vergabe einer höheren Zahl auf der Fibonacci-Skala, dass das Team darauf vorbereitet ist, genügend Ressourcen und Aufwand bereitzustellen – weil es bereits weiß, welcher Arbeitsaufwand in einem solchen Vorhaben steckt.
Umgekehrt erhalten Stories mit weniger Variablen oder einfacheren Ergebnissen niedrigere Zahlen – so lässt sich Zeit und Energie gezielter budgetieren. Kurz gesagt: Agile Planung nimmt Hoffnungen und Träume von der Meeting-Tischplatte und setzt dafür handfeste, greifbare Zahlen an ihre Stelle!
Bitte beachte jedoch, dass Story Points nicht zwangsläufig zwischen Softwareentwicklungsteams vergleichbar sind, da jedes Team den Umfang etwas anders einschätzt. Das bedeutet: Was Team A als eine 5-SP-Story einschätzt, kann für Team B eine 8-SP-Story sein.
Story Point Schätzungen eignen sich auch für kleinere Teams oder Projekte, denn bei dieser Methode bewertet das Team die Aufgaben anhand der Komplexität und des Bearbeitungsaufwands. Weitere Techniken sind beispielsweise das Abschätzen des Aufwands mithilfe von T-Shirt-Größen oder die Planning Poker-Methode.
T-Shirt-Größen
Backlog-Items anhand von T-Shirt-Größen zu schätzen, ist ein interessanter Ansatz, um Projektaufgaben zu priorisieren. Anstatt einer genauen Stundenzahl oder Tagesangabe erhält eine Aufgabe je nach Komplexität oder Unsicherheit eine von vier Größen (klein, mittel, groß, extra-groß).
Es ist eine vereinfachte, aber verblüffend effektive Methode, um sicherzustellen, dass die richtigen Aufgaben zur richtigen Zeit erledigt werden – egal ob du mit kleinen, mittleren oder großen Projekten zu tun hast, wähle einfach die passende Größe. Wichtig ist nur, dass alle Beteiligten im Projekt ein gemeinsames Verständnis davon haben, wie jede Größe mit einem bestimmten geschätzten Aufwand verbunden ist!
Planning Poker
Wenn du nach einer cleveren Methode suchst, um deine Backlog-Items zu schätzen, probiere doch mal Planning Poker aus!
Diese beliebte Technik gibt es bereits seit 2002, als James Grenning den Begriff prägte.
Das Vorgehen ist einfach: Teammitglieder geben ihre Schätzungen anonym ab, indem sie Karten aus dem Planning Poker Deck wählen, die jeweils unterschiedliche Schätzwerte (z. B. die geschätzte Anzahl an Story Points für das Item) darstellen.
So wird jeder ermutigt, seine Meinung zu vertreten, ohne Angst vor Beurteilung oder Spott durch andere. Sobald alle Teammitglieder ihre Schätzungen abgegeben haben und ein Konsens gefunden ist, geht das Team zum nächsten Backlog-Item über.
Die Sprint Planning Agenda
Nachdem du alle notwendigen Vorbereitungen getroffen hast, bist du endlich im Sprint Planning Meeting angekommen. Die Planung eines Scrum Sprints verläuft in der Regel nach folgender Agenda:
- Der Product Owner (PO) stellt sein vordefiniertes Sprint-Ziel vor und teilt seine Idee, wie der Wert des Produkts im kommenden Sprint gesteigert werden kann. Das endgültige Sprint-Ziel wird gemeinsam vom Product Owner und den Entwicklern festgelegt.
- Der PO benennt die (priorisierten) Einträge aus dem Product Backlog, die umgesetzt werden sollen, um das Ziel zu erreichen.
- Das Team schätzt den Aufwand für die einzelnen Einträge, falls dies nicht bereits im Vorfeld (z. B. beim Backlog Refinement) geschehen ist. Falls nötig, verfeinert das Team einzelne Einträge oder Inhalte (z. B. Akzeptanzkriterien).
- Das Team wählt die Product Backlog Items aus, die es bis zum Ende des Sprints liefern wird. An dieser Stelle bespricht der Product Owner die zu erledigenden Aufgaben mit den Entwicklern unter Berücksichtigung des Kundennutzens und des Aufwands. Sind die ausgewählten Einträge ausreichend, um das Sprint-Ziel zu erreichen und Mehrwert für den Kunden zu schaffen? Am Ende entscheiden die Entwickler selbst, wie viel Arbeit sie im Sprint übernehmen. Wichtig: Diese Auswahl ist kein Versprechen gegenüber dem Product Owner und den Stakeholdern, sondern eine Prognose, die auf der Aufwandsschätzung und der durchschnittlichen Team-Velocity basiert.
- Die Entwickler setzen sich dann zusammen, um die ausgewählten Backlog Items in kleinere Aufgaben zu unterteilen. Diese Arbeitspakete sind im Idealfall so zugeschnitten, dass sie an einem Tag oder weniger abgeschlossen werden können.
- Das Sprint Backlog besteht aus dem gemeinsam vereinbarten Sprint-Ziel, den zu bearbeitenden Backlog Items und dem Plan, wie sie umgesetzt werden.
- Viele Teams visualisieren das Sprint Backlog und die anstehenden Aufgaben auf einem Scrum-Board. Jedes Team hat sein eigenes Board und nutzt verschiedene Spalten, um den Fortschritt im Sprint zu dokumentieren. Im Wesentlichen sollten die wichtigsten Spalten aller Boards die folgenden drei sein: „To Do“, „Doing“, „Done“.
In der Praxis teilen viele Scrum-Teams die Sprint-Planung in zwei Phasen auf:
Im ersten Teil finden die ersten vier Punkte der oben beschriebenen Tagesordnung statt. Der Product Owner und das Team klären die Fragen: „Warum ist dieser Sprint wertvoll?“ und „Was wird in diesem Sprint umgesetzt?“ Die Entwickler übernehmen den zweiten Teil ohne PO und beschäftigen sich mit der Ausführung der ausgewählten Arbeiten.
Vorlage für die Tagesordnung des Sprint-Planungsmeetings
Brauchst du eine Agenda-Vorlage für deine Sprint-Planungsmeetings? Lade dir unsere übersichtliche und unkomplizierte Vorlage herunter, um schnell und unkompliziert deine Sprint-Planungsmeetings zu starten. Zusätzlich findest du eine Checkliste und eine E-Mail-Vorlage für noch mehr Komfort.
Zeit, Ordnung in deine Sprint-Planungsmeetings zu bringen
Mit diesem umfassenden Leitfaden bist du jetzt bestens gerüstet, um das Beste aus deinen Sprint-Planungssitzungen herauszuholen. Falls dir dieser Leitfaden gefallen hat, empfehlen wir dir außerdem unseren Ratgeber zu Projektplanungsmeetings.
Wenn du die in diesem Beitrag beschriebenen Schritte befolgst, gelingt es Product Ownern mit Sicherheit, Chaos in Klarheit zu verwandeln und ihrem Team zu helfen, den nächsten Sprint erfolgreich zu meistern. Lies mehr über das Scrum-Framework und weitere Scrum-Zeremonien wie das Daily Scrum hier.
Um weiterhin über organisatorische Tipps und Themen rund um effektive, produktgetriebene Projekte informiert zu bleiben, lade ich dich ein, den Newsletter von The Digital Project Manager zu abonnieren. Von dort aus versorgen wir dich regelmäßig mit Einblicken von Branchenexperten und Projektmanager:innen aus aller Welt.
