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 an einem Strang ziehen und Ergebnisse geliefert werden.
Es ist also an der Zeit, das Chaos zu entwirren und die Erfolgskriterien zu meistern – mit diesem ultimativen Leitfaden, der deine Sprint-Planung so organisiert macht, dass du Marie Kondo Konkurrenz machen kannst! Auch wenn ein gutes Tool für agiles Projektmanagement sehr hilfreich sein kann, geht nichts über menschliches Denken und Teamarbeit, um einen erfolgreichen Sprintplan zu entwickeln.
In diesem umfassenden Leitfaden führe ich dich deshalb durch alles, was du für eine erfolgreiche Sprintplanung brauchst – inklusive der Festlegung eines Sprintziels, wie du dich auf das Sprint-Planungs-Meeting vorbereitest, der Erstellung einer Agenda für das Meeting 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 zu erledigende Arbeit während eines Sprints zu definieren und einen Plan zur Zielerreichung zu erstellen.
In der Regel ist die Sprint-Planungsbesprechung in zwei Teile gegliedert:
- Das „Warum“ und „Was“ des Sprints: Das Team legt das Sprintziel fest und einigt sich darauf, was erledigt werden soll. Es wählt die Backlog-Items aus dem Product Backlog aus, die im Sprint bearbeitet werden. Projektplanungstools mit Funktionen für die Sprintplanung können helfen, Backlog-Items zu organisieren und zu priorisieren, sodass das Team fokussiert bleibt und auf die Sprintziele hinarbeitet.
- Das „Wie“ des Sprints: Die Entwickler besprechen die Details der einzelnen Backlog-Items und zerlegen sie in Aufgaben. Jede Aufgabe wird so zugeschnitten, dass sie innerhalb eines Arbeitstags oder weniger erledigt werden kann und mit einem Task-Management-Tool nachverfolgt werden kann.
Je nach Länge des Sprints dauert das Planungsmeeting zwischen zwei und acht Stunden. Es sollte entsprechend der Sprintlänge zeitlich begrenzt werden (z. B. maximal vier Stunden für einen zweiwöchigen Sprint).
Am Ende des Meetings sollten das Sprintziel und die zu erledigenden Aufgaben festgelegt sein und der Sprint offiziell gestartet werden.
Warum ist Sprint-Planung wichtig?
Sprint-Planung ist wichtig, weil sie eine klare Richtung für den bevorstehenden Sprint eines Teams vorgibt. Eine gut durchgeführte Sprint-Planungssitzung kann:
- Ein gemeinsames, klares Verständnis von Projektzielen und -vorgaben schaffen
- Teams ermöglichen, Arbeitsaufgaben für den bevorstehenden Sprint zu priorisieren und auszuwählen
- Eine effektive Ressourcenzuteilung und Zeitmanagement fördern
- Die Zusammenarbeit und Kommunikation unter den Teammitgliedern fördern
Insgesamt ist die Sprint-Planung ein entscheidender Vorbereitungsschritt im agilen Projektmanagement. Sie legt die Grundlage für einen gut organisierten und effizienten Sprint und befähigt Teams dazu, hochwertige Ergebnisse innerhalb des festgelegten Zeitrahmens zu liefern.
Wer ist an der Sprint-Planung beteiligt?
Kurz gesagt: Das gesamte Scrum-Team sollte an der Sprint-Planung teilnehmen und am Scrum-Event zu Beginn jedes Sprints teilnehmen. Zu diesen Teammitgliedern gehören zum Beispiel:
- Der Product Owner: Bringt die Produktvision ein, klärt Anforderungen und priorisiert die Backlog-Items, die in den Sprint aufgenommen werden.
- Der Scrum Master (in einigen Teams als agiler Coach bezeichnet und nicht mit einem Projektmanager zu verwechseln): Moderiert das Meeting, stellt sicher, dass der vereinbarte Workflow eingehalten wird, und sorgt dafür, dass die Teilnehmer ein gemeinsames Verständnis des Sprintziels entwickeln.
- Die Entwickler: Bringen technisches Fachwissen ein und schätzen den Aufwand sowie die Machbarkeit für die Umsetzung von User Stories ein.
Manchmal nehmen auch Stakeholder aus dem Unternehmen als beratende Experten teil, wenn sie wichtige Perspektiven oder hilfreiches Wissen einbringen können.
Wie bereitet man sich auf das Sprint-Planungs-Meeting vor?
Für eine effektive Sitzung sollte der Product Owner (PO) Folgendes vorbereiten:
- Die Erkenntnisse aus dem letzten Sprint-Review und der Sprint-Retrospektive sowie das Feedback der Stakeholder im Backlog.
- Ein Überblick über die bereits geleistete Arbeit.
Zusätzlich sollte sich der Product Owner auf ein Sprint-Planungs-Meeting vorbereiten, indem er mehrere Prozesse durchführt, auf die ich unten noch genauer eingehe. Diese beinhalten:
- Vordefinieren des Sprint-Ziels mit zugehörigen, priorisierten Backlog-Einträgen, die in der Planung besprochen werden können.
- Regelmäßige Überarbeitung des Backlogs, bei der die wichtigsten Einträge aktualisiert werden.
- Bewertung der Teamgeschwindigkeit (Velocity) und Kapazität für den nächsten Sprint.
Diese drei Aktivitäten werde ich im Folgenden näher beschreiben.
Was ist ein Sprint-Ziel?
Während der Sprint-Planung legen der Product Owner und die Entwickler gemeinsam ein konkretes Sprint-Ziel fest. Das Sprint-Ziel beschreibt das Ergebnis oder den Mehrwert des neuen Sprints, an dem das Team arbeitet. Es ist ein kurzfristiges Zwischenziel auf dem Weg zum fertigen Produkt.
Das Ziel ist, dass am Ende des Sprints ein auslieferbares Produkt-Inkrement vorliegt, das den Kunden bereits einen Nutzen bietet.
Was ist ein Backlog?
Wenn du Product Owner bist, hast du den Begriff "Backlog" wahrscheinlich schon unzählige Male gehört. Aber was ist das eigentlich genau? Klar, auf einer grundlegenden Ebene wissen wir alle, was das ist – eine Liste von Aufgaben oder Funktionalitäten, die erledigt werden müssen.
Wenn es aber um Details wie den Unterschied zwischen Product Backlog und Sprint Backlog geht, wird die Sache schnell kompliziert – also mach dich bereit, wir tauchen direkt ein!
Product Backlog vs Sprint Backlog
Das Scrum-Team sammelt alle User Stories, Epics und Aufgaben, die für das fertige Produkt benötigt werden, im Product Backlog. Der Product Owner priorisiert die Backlog-Einträge so, dass die Stories mit dem höchsten Nutzen für die Kunden oben stehen. Diese Priorisierung erfolgt in der Regel gemeinsam mit den Entwicklern.
Das Product Backlog ist jedoch keine abschließende Liste, die zu Beginn der Entwicklungsphase erstellt und dann abgearbeitet wird. Nein, diese Liste wächst und verändert sich laufend.
Sie wächst zum einen durch Erkenntnisse, die während der Sprints gewonnen werden, und zum anderen durch neue Anforderungen, die im Verlauf hinzukommen. Daher ist eine regelmäßige Überarbeitung des Backlogs notwendig, um auf diese Änderungen zu reagieren.
Ein Beispiel: Angenommen, das Product Backlog umfasst alle Stories, die für die Erstellung einer Website notwendig sind, z. B. die Startseite, das Kontaktformular und die Produktseiten. Stellt das Marketingteam nun fest, dass auf der Website unbedingt noch ein Blog-Bereich benötigt wird, kann dies ergänzt und entsprechend priorisiert werden.
Im Vergleich zum Product Backlog enthält das Sprint Backlog nur die Backlog-Einträge, die für den aktuellen Sprint ausgewählt wurden, sowie das dazugehörige Sprint-Ziel.
Wie schätzt man Einträge im Backlog?
Wie viel Arbeit kann ein Team im Sprint erledigen? Das ist eine der zentralen Fragen, die Entwickler während der Sprint-Planung beantworten müssen. Um eine Prognose treffen zu können, führen sie eine Schätzung durch.
Das kann durchaus herausfordernd sein, da das Team mit vielen unbekannten Variablen zu tun hat. Mit zunehmender Erfahrung aus abgeschlossenen Sprints werden die Schätzungen jedoch immer verlässlicher.
Wie berechnet man Teamgeschwindigkeit (Velocity) und Kapazität?
Bevor mit der Schätzung begonnen werden kann, ist es wichtig, die durchschnittliche Leistung der vorherigen Sprints (Velocity) sowie die verfügbare Teamkapazität für den kommenden Sprint zu kennen, die etwa durch Schulungen, Urlaub usw. verringert sein könnte.
Basierend auf diesen Überlegungen schätzt das Team die Menge an Arbeit (Velocity) ein, die es im Sprint übernehmen kann, bewertet dann die einzelnen Backlog-Einträge und entscheidet, wie viele davon im Sprint Backlog aufgenommen werden.
Angenommen, die durchschnittliche Velocity der letzten Sprints (bei zweiwöchigem Zyklus) lag bei 40 Story Points und es wird kein wesentlicher Personalausfall erwartet, dann plant das Team entsprechend mit dieser Geschwindigkeit weiter (das heißt: Für den kommenden Sprint werden Einträge in das Sprint Backlog aufgenommen, bis etwa 40 Story Points erreicht sind).
Während die durchschnittliche Zeit zur Erledigung einer Aufgabe in der Regel mit einem guten Zeiterfassungstool nachverfolgt werden kann, gibt es auch verschiedene andere Schätzmethoden, mit denen du die agile Kapazitätsplanung durchführen und die Leistung deines Teams bestimmen kannst.
Schätzmethoden: Ein kurzer Überblick
Möchtest du das Thema Schätzung besser verstehen? Mit verschiedenen Methoden und Einflussfaktoren kann es anfangs einschüchternd wirken – aber keine Sorge! Wenn du die Grundlagen verstanden hast, bist du bestens darauf vorbereitet, dein Backlog im Handumdrehen zu schätzen.
Story Points
Viele agile Teams, die an langfristigen Projekten arbeiten, schätzen ihre Geschwindigkeit in Story Points.
Story Points sind eine abstrakte Einheit, die das Team verwendet, um den für die Umsetzung eines Backlog-Items erforderlichen Aufwand zu schätzen. Diese Einschätzung basiert auf drei Kriterien:
- Arbeitsmenge: Wie viele Teilaufgaben müssen erledigt werden, um die User Story abzuschließen?
- Risiken und Unsicherheit: Sind alle Anforderungen eindeutig oder könnte es zu unerwarteten Verzögerungen und Änderungen kommen?
- Komplexität der Story: Hängen einzelne Teilaufgaben voneinander ab, sodass dadurch die Komplexität der Story zunimmt? Und gibt es Abhängigkeiten außerhalb des Teams?
Die Fibonacci-Folge & Primzahlen
Agiles Planen mit der Fibonacci-Folge und Primzahlen unterstützt Teams dabei, Prognosen nicht allein nach Bauchgefühl oder Optimismus zu treffen, sondern nach Grundsätzen numerischer Logik.
Wenn eine User Story viele Variablen sowie einen großen oder komplexen Umfang hat, bedeutet eine höhere Zahl auf der Fibonacci-Skala, dass das Team bereit ist, entsprechend mehr Ressourcen und Aufwand einzuplanen – denn sie kennen bereits den damit verbundenen Arbeitsaufwand.
Auf der anderen Seite erhalten Stories mit weniger Variablen oder einfacheren Ergebnissen niedrigere Werte – so lässt sich Zeit und Energie gezielter einplanen. Kurz gesagt: Agiles Planen holt Wünsche und Träume vom Besprechungstisch und ersetzt sie durch konkrete, greifbare Zahlen!
Beachte jedoch, dass Story Points nicht zwangsläufig über verschiedene Software-Teams hinweg vergleichbar sind, da jedes Team den Umfang ein wenig anders einschätzt. Das heißt, was Team A als 5 SP-Story bewertet, kann vom Team B als 8 SP-Story eingeschätzt werden.
Die Schätzung mit Story Points eignet sich auch für kleinere Teams oder Projekte, da die Aufgaben hier anhand der Komplexität und der benötigten Zeit eingeschätzt werden. Andere Methoden sind die Aufwandsschätzung über T-Shirt-Größen oder per Planning Poker.
T-Shirt-Größen
Das Schätzen von Backlog-Items mittels T-Shirt-Größen ist ein interessanter Ansatz, um Projektaufgaben nach Priorität einzuordnen. Anstatt einer genauen Anzahl von Stunden oder Tagen wird der Aufgabe je nach Grad an Komplexität oder Unsicherheit eine der vier Größen (Small, Medium, Large, Extra Large) zugewiesen.
Das ist eine vereinfachte, aber überraschend effektive Methode, damit die richtigen Aufgaben zur richtigen Zeit erledigt werden – egal, ob kleine, mittlere oder große Projekte: Du musst nur die passende Größe wählen. Wichtig ist jedoch, dass sich alle am Projekt Beteiligten einig sind, wie die einzelnen Größen mit einem bestimmten Aufwand verknüpft sind!
Planning Poker
Wenn du eine clevere Methode suchst, um deine Backlog-Items zu schätzen, probiere doch mal Planning Poker aus!
Diese bei agilen Teams beliebte Technik gibt es schon seit 2002, als James Grenning den Begriff etablierte.
Die Vorgehensweise ist einfach: Die Teammitglieder geben ihre Schätzwerten anonym ab, indem sie Karten aus einem Planning-Poker-Kartenset wählen, die jeweils für eine bestimmte Schätzung (zum Beispiel der Anzahl Story Points für das Item) stehen.
Dadurch wird sichergestellt, dass alle ihre Meinung äußern, ohne Angst vor Bewertung oder Spott zu haben. Sobald alle Teammitglieder ihre Schätzungen abgegeben und einen Konsens gefunden haben, geht das Team zum nächsten Item über.
Die Sprint-Planungsagenda
Nachdem du alle nötigen Vorbereitungen getroffen hast, ist es endlich Zeit für das Sprint Planning Meeting. Die Planung eines Scrum Sprints folgt in der Regel dieser 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 zuvor geschehen ist (z.B. im Backlog Refinement). Falls nötig, verfeinert das Team einzelne Einträge oder Inhalte (z.B. Given-When-Then-Akzeptanzkriterien).
- Das Team wählt die Product-Backlog-Einträge aus, die es bis zum Ende des Sprints liefern wird. An diesem Punkt bespricht der Product Owner die abzuarbeitenden Aufgaben zusammen mit den Entwicklern anhand von Kundenmehrwert und Aufwand. Sind die gewählten Einträge ausreichend, um das Sprint-Ziel zu erreichen und Wert für den Kunden zu schaffen? Letztendlich entscheiden die Entwickler selbst, wie viel Arbeit sie im Sprint übernehmen. Wichtig: Diese Auswahl ist kein Commitment gegenüber dem Product Owner und den Stakeholdern, sondern eine Prognose auf Grundlage der Aufwandsschätzung und der durchschnittlichen Team-Velocity.
- Die Entwickler kommen dann zusammen, um die ausgewählten Backlog-Einträge in kleinere Aufgaben herunterzubrechen. Idealerweise sind diese Arbeitspakete so zugeschnitten, dass sie an einem Tag oder weniger abgearbeitet werden können.
- Das Sprint-Backlog besteht aus dem gemeinsam vereinbarten Sprint-Ziel, den zu bearbeitenden Backlog-Einträgen und dem Plan, wie diese umgesetzt werden.
- Viele Teams visualisieren das Sprint-Backlog und die zu erledigenden Arbeiten auf einem Scrum-Board. Jedes Team hat sein eigenes Board und verwendet verschiedene Spalten, um den Fortschritt im Sprint zu dokumentieren. Im Wesentlichen sollten die drei wichtigsten Spalten auf allen Boards die folgenden sein: „Zu erledigen“, „In Arbeit“, „Erledigt“.
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 Agenda 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 führen den zweiten Teil ohne den PO durch und beschäftigen sich damit, wie sie die ausgewählten Aufgaben erledigen.
Sprint-Planungs-Meeting Agenda-Vorlage
Benötigen Sie eine Agenda-Vorlage für Ihre Sprint-Planungs-Meetings? Laden Sie unsere übersichtliche und unkomplizierte Vorlage herunter, um schnell mit Ihren Sprint-Planungs-Meetings durchzustarten. Zusätzlich finden Sie eine Checkliste und eine E-Mail-Vorlage für noch mehr Komfort.
Zeit, Ihre Sprint-Planungs-Meetings nach Marie Kondo zu ordnen
Mit diesem umfassenden Leitfaden sind Sie nun bestens gerüstet, um das Beste aus Ihren Sprint-Planungs-Sitzungen herauszuholen. Wenn Sie diesen Leitfaden hilfreich fanden, empfehlen wir Ihnen außerdem, unseren Leitfaden zu Projektplanungs-Meetings anzusehen.
Wenn Sie die in diesem Beitrag beschriebenen Schritte befolgen, haben Product Owner beste Chancen, Chaos in Klarheit zu verwandeln und ihrem Team zum Erfolg im nächsten Sprint zu verhelfen. Lesen Sie mehr über das Scrum-Framework und andere Scrum-Zeremonien, wie das tägliche Scrum, hier.
Um weiterhin organisatorische Tipps und Schwerpunkte zu Themen rund um effektive projektgetriebene Arbeit zu erhalten, lade ich Sie ein, den Newsletter des Digital Project Managers zu abonnieren. So liefern wir Ihnen weiterhin Einblicke von Branchenexperten und Projektmanager:innen aus aller Welt.
