Das Sprint-Planungsmeeting – Schritt für Schritt

Die Sprint-Planung ist die Besprechung, mit der ein Sprint eröffnet wird. In dieser Besprechung einigt sich das Team auf ein Sprint-Ziel und legt fest, welchen Teil des Backlogs es realistisch gesehen abschließen kann, wodurch aus einer priorisierten Liste ein Plan wird, an den das Team tatsächlich glaubt. Ein Backlog ist eine Wunschliste, bis jemand entscheidet, was als Nächstes umgesetzt wird. Diese Entscheidung fällt im Rahmen der Sprint-Planung.

Wenn es gut gemacht wird, dauert es ein oder zwei Stunden, und das Team geht mit dem Wissen nach Hause, was es zu tun hat und warum. Wenn es schlecht gemacht wird, wird es zu einer Sitzung, in der lediglich das Backlog durchgelesen wird, bei der der Product Owner Tickets zuweist und alle zustimmend nicken – und das „Engagement“ bröckelt bis zum Mittwoch still und leise.

Warum, was und wie

Der Scrum Guide gliedert die Planung des Sprints anhand von drei Fragen, die Sie am besten in dieser Reihenfolge beachten sollten:

• Warum ist dieser Sprint wertvoll? Die Antwort liegt im Sprintziel: ein Satz, hinter dem das gesamte Team stehen kann. Einigen Sie sich darauf, bevor Sie sich mit dem Backlog befassen. Das Festlegen eines Sprintziels ist eine Kunst für sich.
• Was lässt sich in diesem Sprint erledigen? Die Entwickler wählen Aufgaben aus dem oberen Bereich des Backlogs aus, die dem Ziel dienen, bis sie an die Grenze ihrer Kapazität stoßen. Hierbei handelt es sich um eine Prognose und nicht um ein unter Eid abgegebenes Versprechen.
• Wie wird die ausgewählte Arbeit umgesetzt? Das Team gliedert die wichtigsten Punkte so weit auf, dass ein Plan vorliegt, mit dem man beginnen kann: Aufgaben, Vorgehensweise, offensichtliche Risiken. Nicht jeder Punkt bis hin zur letzten Teilaufgabe; sondern gerade so viel, dass man zuversichtlich beginnen kann.

Das Ergebnis ist ein Sprint-Backlog: das Ziel, die ausgewählten Elemente und der Plan für deren Umsetzung.

Zuerst den Umfang festlegen, dann planen

Die mit Abstand nützlichste strukturelle Vorgehensweise besteht darin, die Planung in zwei klar voneinander getrennten Durchgängen durchzuführen, anstatt in einem einzigen, unscharfen.

Im ersten Teil geht es um den Umfang. Der Product Owner stellt das Ziel und die in Frage kommenden Elemente in der Reihenfolge ihrer Priorität vor. Das Team stellt klärende Fragen, prüft jedes Element anhand der Definition von „bereit“ und nimmt so viele Aufgaben an, bis die Kapazität erschöpft ist. Halten Sie hier inne. Die Versuchung, „noch eine“ kleine Story unterzubringen, ist genau der Grund, warum Sprints überbelegt werden.

Teil zwei ist die Planung. Nun befasst sich das Team eingehend mit den ausgewählten Elementen, gliedert diese in einzelne Aufgaben auf, ermittelt Abhängigkeiten und legt fest, wer welche Aufgabe als Erstes übernimmt. An dieser Stelle entdeckt man die Story, die auf den ersten Blick wie eine 3 aussah, hinter deren vagem Akzeptanzkriterium sich jedoch tatsächlich eine Woche Arbeit verbirgt.

Wenn man diese beiden Aspekte voneinander trennt, verhindert man, dass die Besprechung bei jedem einzelnen Punkt zwischen den Fragen „Sollten wir das aufnehmen?“ und „Wie würden wir das umsetzen?“ hin- und hergerissen ist.

Was Sie im Zimmer benötigen

Die Sprintplanung funktioniert nur, wenn die Eingaben bereits vorliegen. In der Besprechung werden die Eingaben in einen Plan umgesetzt; sie werden nicht erst vor Ort erstellt.

• Ein verfeinertes, nach Prioritäten geordnetes Backlog. Die obersten Punkte sollten bereits verstanden und grob in ihrem Umfang eingeschätzt sein. Wenn das Team eine Story erst bei der Planung zum ersten Mal sieht, führen Sie die Backlog-Verfeinerung im falschen Meeting durch, und dieses wird sich in die Länge ziehen. Die Verfeinerung ist die Grundlage; die Planung ist die Entscheidung.
• Eine tatsächliche Kapazitätszahl. Nicht „zwei Wochen mal die Teamgröße“, sondern die Stunden, die nach Abzug von Urlaub, Besprechungen, Support-Schichten und Unterbrechungen tatsächlich zur Verfügung stehen. Siehe Velocity und Kapazitätsplanung.
• Das gesamte Team. Die Entwickler erstellen die Prognose, daher müssen die Entwickler anwesend sein. Eine Planung durch Beauftragte führt zu Verpflichtungen, für die niemand die Verantwortung übernimmt.

Wer leitet das Unternehmen?

Der Scrum Master moderiert: Er sorgt für die Einhaltung des Zeitrahmens, hält die beiden Phasen voneinander getrennt und verhindert, dass das Meeting dazu abgleitet, jeden Sonderfall bis ins Detail zu lösen. Der Product Owner bringt das Ziel und das priorisierte Backlog mit und beantwortet „Warum“- und „Was“-Fragen direkt vor Ort. Die Entwickler entscheiden, wie viel sie übernehmen und wie sie es umsetzen werden.

Dieser letzte Punkt ist entscheidend: Die Prognose liegt in der Hand derjenigen, die die Arbeit leisten. Ein Plan, der von oben vorgegeben und schweigend hingenommen wird, ist keine Verpflichtung. Er ist lediglich eine Warteschlange.

Wie lange es dauern sollte

Der Scrum Guide sieht für einen einmonatigen Sprint eine Planungszeit von bis zu acht Stunden vor, für kürzere Sprints entsprechend weniger, also etwa zwei Stunden pro Sprintwoche. Ein zweiwöchiger Sprint sollte etwa vier Stunden in Anspruch nehmen, oft sogar weniger, sobald ein Team einen gleichmäßigen Rhythmus gefunden hat.

Betrachten Sie dies als Obergrenze, nicht als Zielvorgabe. Teams, die regelmäßig die gesamte Zeitvorgabe benötigen, nehmen fast immer bereits während der Planung Anpassungen vor. Legen Sie die Eingaben fest, dann verkürzt sich die Besprechung von selbst. Wenn Sie eine Aufschlüsselung nach Minuten wünschen, finden Sie diese im Kapitel Agenda für den Sprint.

Wo es schiefgeht

Drei Fehlerquellen sind für die meisten schlecht verlaufenden Planungssitzungen verantwortlich.

Die Lesesitzung. Der Product Owner trägt die Tickets vor, und das Team hört zu. Es werden keine Entscheidungen getroffen, da niemand entscheidet; das Team wird lediglich informiert. Bei der Planung sollte das Gefühl vorherrschen, dass das Team selbst wählt und nicht, dass ihm Aufgaben zugewiesen werden.

Die Überlastung. Die Kapazität wird als ehrgeiziges Ziel betrachtet. Das Team legt seine bisher höchste Arbeitsgeschwindigkeit als Mindeststandard fest und fügt aus Ehrgeiz noch etwas hinzu. Dann führen eine Störung, ein Krankheitstag und eine unterschätzte Story dazu, dass der Sprint zu einem hektischen Gerangel wird. Planen Sie mit einer bescheidenen Zahl, nicht mit einer heroischen.

Planung ohne Ziel. Das Team wählt eine bunte Mischung aus zusammenhanglosen Tickets aus, und wenn der Sprint knapp wird, gibt es keine Richtlinie dafür, was gestrichen werden soll, sodass sich alles ein wenig verzögert und nichts in einwandfreiem Zustand ausgeliefert wird. Das Ziel ist es, das Ihnen unter Druck Aufschluss darüber gibt, welche Tickets Sie streichen sollten.

Bereiten Sie die Eingaben vor, trennen Sie den Umfang vom Plan und übertragen Sie die Verantwortung für die Prognose an das Team. Im weiteren Verlauf dieses Leitfadens werden die einzelnen Punkte ausführlich behandelt. Beginnen Sie mit der Tagesordnung oder laden Sie sich die Vorlage für die Sprintplanung herunter.

Häufig gestellte Fragen

Was ist eine Sprintplanung?

Die Sprintplanung ist das Scrum-Event, mit dem ein Sprint eröffnet wird. Das Team legt ein Sprintziel fest, wählt die Backlog-Elemente aus, deren Fertigstellung es voraussichtlich bewältigen kann, und entwirft einen Plan, wie die Arbeit erledigt werden soll. Dabei werden drei Fragen beantwortet: Warum ist der Sprint sinnvoll? Was wird entwickelt? Und wie?

Wie lange sollte die Sprintplanung dauern?

Legen Sie die Zeitvorgabe auf etwa zwei Stunden pro Sprintwoche fest, also ungefähr zwei Stunden für einen einwöchigen Sprint, vier Stunden für einen zweiwöchigen Sprint und bis zu acht Stunden für einen Monat. Dies ist eine Obergrenze, kein Ziel. Wenn Sie regelmäßig die gesamte Zeitvorgabe benötigen, war das Backlog zu Beginn in der Regel noch nicht bereit.

Was sind die wichtigsten Schritte bei der Planung des Sprints?

Bestätigen Sie die tatsächliche Kapazität des Teams für den Sprint; legen Sie ein Sprintziel fest; wählen Sie Backlog-Elemente aus, die diesem Ziel dienen, bis die Kapazität erreicht ist; gliedern Sie die obersten Elemente in einen umsetzbaren Plan auf; und vergewissern Sie sich, dass das Team der Prognose zustimmt. Zuerst den Umfang festlegen, dann planen – in dieser Reihenfolge.

Wer leitet die Sprintplanung?

Der Scrum Master moderiert den Prozess und sorgt dafür, dass er innerhalb des festgelegten Zeitrahmens bleibt. Der Product Owner bringt ein priorisiertes, verfeinertes Backlog mit und erläutert die Gründe dafür. Die Entwickler entscheiden, wie viel sie übernehmen können und wie sie es umsetzen werden: Die Prognose liegt in ihrer Verantwortung, sie wird nicht vom Product Owner vorgegeben.