Das Sprint-Planungsmeeting – Schritt für Schritt

Die Sprintplanung ist die Besprechung, mit der ein Sprint eröffnet wird. In dieser Besprechung einigt sich das Team auf ein Sprintziel 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 wird in der Sprintplanung getroffen.

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, bei der lediglich der Backlog durchgelesen wird, in 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 in dieser Reihenfolge beachtet werden sollten:

• Warum ist dieser Sprint wertvoll? Die Antwort liegt im Sprintziel – einem Satz, hinter dem das gesamte Team stehen kann. Einigen Sie sich darauf, bevor Sie mit dem Backlog beginnen. 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 loslegen 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 Schritten durchzuführen, anstatt in einem einzigen, unscharfen Durchgang.

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 – es gliedert sie in einzelne Aufgaben auf, ermittelt Abhängigkeiten und legt fest, wer welche Aufgabe zuerst übernimmt. An dieser Stelle entdeckt man die Story, die zunächst wie eine 3 aussah, hinter einem vagen Akzeptanzkriterium 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 übernehmen?“ und „Wie würden wir das umsetzen?“ hin- und hergerissen wird.

Was Sie im Zimmer benötigen

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

• Ein verfeinertes, nach Prioritäten geordnetes Backlog. Die obersten Elemente 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 es wird sich in die Länge ziehen. Die Verfeinerung ist die Grundlage; die Planung ist die Entscheidung.
• Eine tatsächliche Kapazitätsangabe. Nicht „zwei Wochen mal die Teamgröße“, sondern die Stunden, die nach Abzug von Urlaub, Besprechungen, Support-Einsätzen 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 die Organisation?

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 Einzelfall bis ins Detail zu lösen. Der Product Owner bringt das Ziel und das priorisierte Backlog mit und beantwortet „Warum“- und „Was“-Fragen sofort. 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 Vorgabe.

Wie lange dies dauern sollte

Der Scrum Guide sieht für die Planung eines einmonatigen Sprints bis zu acht Stunden vor, für kürzere Sprints entsprechend weniger – also etwa zwei Stunden pro Sprintwoche. Bei einem zweiwöchigen Sprint sollten es etwa vier Stunden sein, 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 im Vordergrund stehen, 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 erhöht diesen Wert noch ein wenig, um Ambitionen zu zeigen. Doch dann führen ein Ausfall im Support, 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 kein Kriterium dafür, was gestrichen werden soll – daher verzögert sich alles ein wenig, und nichts wird in einwandfreiem Zustand ausgeliefert. Das Ziel gibt Ihnen vor, welche Tickets Sie unter Druck aufgeben müssen.

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 Sprint-Planungsvorlage 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 skizziert, 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 das Zeitfenster auf etwa zwei Stunden pro Sprintwoche fest – also ungefähr zwei Stunden für einen einwöchigen Sprint, vier für einen zweiwöchigen Sprint und bis zu acht für einen Monat. Das ist eine Obergrenze, kein Ziel. Wenn Sie regelmäßig das gesamte Zeitfenster 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ätsgrenze 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 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, nicht in der des Product Owners, der sie zuweisen würde.