Sprint-Planung: die Zeremonie, mit der der Sprint eröffnet wird

Die Sprintplanung ist die Zeremonie, mit der der Sprint eröffnet wird. Das Team legt fest, was es liefern wird, und skizziert, wie dies geschehen soll – dabei wird ein Teil des Produkt-Backlogs in ein Sprint-Backlog und ein einziges, klares Sprintziel umgewandelt. Bei guter Durchführung dauert dies einige Stunden und verschafft dem Team zwei Wochen ungestörter Konzentration. Bei schlechter Durchführung ist es eine Übung zum Auffüllen der Warteschlange, über die das Team den Rest des Sprints stillschweigend neu verhandelt.

Dieses Kapitel bietet eine Zusammenfassung auf der Ebene der Zeremonie. Den vollständigen Ablauf – einschließlich Tagesordnung, Rollen, Kapazitätsberechnungen und ausgearbeiteten Beispielen für Sprintziele – finden Sie im vollständigen Leitfaden zur Sprintplanung.

Wo die Planung im Zyklus angesiedelt ist

Die Sprintplanung ist die erste der agilen Zeremonien, und ihr Ergebnis dient als Bezugspunkt für alle weiteren. Beim täglichen Stand-up wird der Fortschritt anhand des hier festgelegten Sprintziels überprüft; bei der Sprint-Review wird geprüft, ob das Team dieses Ziel erreicht hat. Gelingt die Planung nicht, wird der Rest des Sprints damit verbracht, den Fehler auszugleichen.

Was die Planung beantwortet: Warum, Was, Wie

Der Scrum Guide gliedert die Besprechung anhand von drei Fragen – warum ist dieser Sprint wertvoll, was kann getan werden und wie wird es umgesetzt – wobei die Reihenfolge von Bedeutung ist.

Klären Sie zunächst das Warum. Ein Sprintziel, das Sie in einem Satz formulieren können, ist mehr wert als ein Backlog, das Sie nicht abarbeiten können. Das Ziel ist das, was das Team schützt, wenn der Plan mitten im Sprint auf die Realität trifft; der Umfang passt sich daran an, nicht umgekehrt.

Dann das Was: Der Product Owner legt Prioritäten fest, die Entwickler wählen Aufgaben aus, von denen sie glauben, dass sie diese abschließen können, und beide Seiten verhandeln so lange, bis eine Vereinbarung vorliegt, der beide Seiten vertrauen. Und das Wie: Die Entwickler gliedern die wichtigsten Aufgaben in einen Plan auf, der ausreicht, um loszulegen – kein Gantt-Diagramm, sondern gerade so viel Konzeption, dass klar ist, dass die Arbeit real ist.

Ein- und Ausgänge

Eine Planung ist nur so gut wie das, was man selbst in sie einbringt.

• Voraussetzungen: ein verfeinertes Produkt-Backlog (bereits geklärte und in Umfang bezifferte Elemente), die Kapazität des Teams für diesen Sprint sowie eine Einschätzung der aktuellen Velocity.
• Ergebnisse: ein Sprintziel und ein Sprint-Backlog, an die das Team wirklich glaubt.

Die Größenabschätzung erfolgt im Raum. Die meisten Teams gelangen mit Planning Poker schnell zu einer gemeinsamen Schätzung, anstatt stundenlang zu diskutieren – im Leitfaden zur Schätzung erfahren Sie, warum Punkte hier der Zeit vorgezogen werden.

Die zu beachtende Ausfallart

Überlastung. Teams planen mit 100 % der theoretischen Kapazität und vergessen dabei, dass die Velocity bereits die Besprechungen, die Unterbrechungen und die Person, die am Donnerstag abwesend ist, einkalkuliert. Planen Sie Kapazität, statt zu hoffen: Ein Plan, den das Team umsetzt, schafft Vertrauen, während ein Plan, den das Team aufgibt, dieses Vertrauen stillschweigend zerstört.

Ein weiteres Anzeichen ist ein Plan, der auf einem unausgereiften Backlog basiert. Wenn die Planung zu einer Sitzung wird, in der lediglich Klarstellungen vorgenommen und Aufgaben aufgeteilt werden, findet keine Backlog-Verfeinerung statt – beheben Sie dieses Problem bereits im Vorfeld, und die Planung verläuft reibungslos.

Häufig gestellte Fragen

Wie lange sollte die Sprintplanung dauern?

Legen Sie dafür etwa zwei Stunden pro Woche im Sprint fest – also bis zu vier Stunden für einen zweiwöchigen Sprint und bis zu einem ganzen Tag für einen einmonatigen Sprint. Wenn die Planung regelmäßig bis zur letzten Minute dauert, ist das Backlog unausgereift und das Team führt Verfeinerungsarbeiten durch, die es eigentlich schon früher hätte erledigen sollen.

Wer nimmt an der Sprintplanung teil?

Das gesamte Scrum-Team: die Entwickler, der Product Owner und der Scrum Master. Der Product Owner legt die Prioritäten fest und erläutert die Gründe dafür; die Entwickler entscheiden, was sie realistisch übernehmen können und wie sie es umsetzen werden; der Scrum Master sorgt dafür, dass die Sitzung im Zeitrahmen bleibt und fokussiert verläuft. Stakeholder nehmen nicht teil.

Was ist der Unterschied zwischen dem Sprintziel und dem Sprint-Backlog?

Das Sprintziel ist der einzelne Satz, der verdeutlicht, warum es sich lohnt, den Sprint durchzuführen – das Ergebnis, zu dem sich das Team verpflichtet. Das Sprint-Backlog umfasst die Elemente und Aufgaben, von denen das Team erwartet, dass sie es dorthin führen. Das Ziel ist für den Sprint feststehend; das Backlog kann sich entsprechend anpassen, je mehr das Team lernt.