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, 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 Ablauf (die Tagesordnung, die Rollen, die Kapazitätsberechnungen sowie Beispiele für ausgearbeitete 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 anderen. Beim täglichen Standup-Meeting wird der Fortschritt anhand des hier festgelegten Sprintziels überprüft; bei der Sprint-Review wird geprüft, ob das Team dieses Ziel erreicht hat. Wenn die Planung fehlschlägt, wird der Rest des Sprints damit verbracht, die Folgen dieses Fehlers auszugleichen.

Was die Planung beantwortet: Warum, Was, Wie

Der Scrum Guide gliedert das Meeting 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 in sie 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 jüngsten 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. Lesen Sie im Leitfaden zur Schätzung hier nach, warum Punkte der Zeit überlegen sind.

Die zu beachtende Ausfallart

Überlastung. Teams planen bis zu 100 % der theoretischen Kapazität und vergessen dabei, dass in der Velocity bereits die Besprechungen, die Unterbrechungen und die Person, die am Donnerstag abwesend ist, berücksichtigt sind. Planen Sie auf der Grundlage der Kapazität, nicht auf der Grundlage von 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 zitiert wird, das es nie abgegeben hat – in eine Verpflichtung umgewandelt und dem Team vorgehalten wird –, wodurch die Planung ins „agile“ Theater abgleitet.

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 Verfeinerung des Backlogs 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 bis zur letzten Minute dauert, ist das Backlog unausgereift und das Team führt Verfeinerungsarbeiten durch, die es bereits 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 gesehen ü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 umfasst die Elemente und Aufgaben, von denen das Team erwartet, dass sie es zu diesem Ziel führen. Das Ziel ist für den Sprint fest vorgegeben; das Backlog kann sich entsprechend anpassen, je mehr das Team lernt.