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 einigt sich darauf, was es liefern wird, und skizziert, wie dies geschehen soll, wobei ein Teil des Produkt-Backlogs in ein Sprint-Backlog und ein einziges, klares Sprintziel umgewandelt wird. 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 Zeremonieebene. Den vollständigen Ablaufplan (Tagesordnung, Rollen, Kapazitätsberechnungen und ausgearbeitete Beispiele für Sprintziele) finden Sie unter dem 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 anderen. 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 realistisch ist.

Ein- und Ausgänge

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

• Eingaben: 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, von denen das Team wirklich überzeugt ist.

Die Größenbestimmung erfolgt im Raum. Die meisten Teams gelangen mit Planning Poker schnell zu einer gemeinsamen Schätzung, anstatt stundenlang zu diskutieren. In dem Leitfaden zur Schätzung erfahren Sie, warum Punkte in diesem Fall der Zeit überlegen sind.

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, nicht Hoffnungen: Ein Plan, den das Team umsetzt, schafft Vertrauen, während ein Plan, den das Team aufgibt, dieses Vertrauen stillschweigend zerstört. Noch gravierender ist es, wenn die vom Team abgegebene Schätzung als ein Versprechen wiedergegeben wird, das es nie gegeben hat, zu einer Verpflichtung umgedeutet und dem Team vorgehalten wird – und genau hier kippt die Planung ins agile Theater.

Ein weiteres Anzeichen ist ein Plan, der auf einem unausgearbeiteten 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 Sprintwoche 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 unter Zeitdruck gerät, ist das Backlog unzureichend aufbereitet und das Team muss Verfeinerungsarbeiten durchführen, 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 eine Satz, der verdeutlicht, warum es sich lohnt, den Sprint durchzuführen: das Ergebnis, zu dem sich das Team verpflichtet. Das Sprint-Backlog ist die Gesamtheit der Elemente und Aufgaben, von denen das Team erwartet, dass sie es dorthin führen. Das Ziel ist für den Sprint festgesetzt; das Backlog kann sich entsprechend anpassen, während das Team neue Erkenntnisse gewinnt.