Sprint Planning

Warum ist dieser Sprint wertvoll für die Stakeholder?

Dieser Artikel erläutert die Änderungen im Scrum Guide von 2020 in Bezug auf das Sprint Planning und beschreibt, wie durch sie bessere Sprintziele gefunden werden können.

Der Scrum Guide von 2017 schlug folgende zwei Fragen für das Sprint Planning vor:

  • Was kann in diesem Sprint fertiggestellt werden? (Forecast)
  • Wie wird die ausgewählte Arbeit erledigt? (Sprint Backlog)

Der Scrum Guide von 2020 fügt eine weitere Frage hinzu und setzt sie an die erste Stelle:

  • Warum ist dieser Sprint wertvoll für die Stakeholder? (Sprint Goal)

Die Antwort auf die letzte Frage findet sich im Sprint Goal wieder, das jetzt ein Commitment für das Sprint Backlog ist.

Das Sprint Planning

Im Sprint Planning legt das Scrum Team die Arbeiten fest, die während des nächsten Sprints umgesetzt werden sollen. Es behandelt für gewöhnlich zwei Themen.

Zunächst geht es um die Frage, „was wollen wir erreichen“? Um diese Frage zu klären, erläutert der Product Owner den Developern, welche Product Backlog Items er oder sie für die wichtigsten hält. Bei der Diskussion darüber entsteht ein gemeinsames Verständnis der gewünschten Produkteigenschaften, der Akzeptanzkriterien und der Größe der Product Backlog Items. Die Developer entscheiden anschließend selbstständig, wie viele der vorgestellten Product Backlog Items sie in das Sprint Backlog ziehen. Die ausgewählten Product Backlog Items sind eine Prognose (Forecast) über die Arbeit, die im Sprint voraussichtlich realisiert werden kann.

Das zweite Thema betrifft die Umsetzung der geplanten Arbeit. Die Developer (in der Praxis häufig ohne den Product Owner, der aber für Rückfragen bereitstehen sollte) klären, wie die ausgewählte Arbeit erledigt werden kann, zerlegen die ausgewählten Product Backlog Items in kleinere Arbeitspakete und sprechen die weiteren Arbeiten im Team ab. So entsteht ein Plan zur Umsetzung der ausgewählten Product Backlog Items, der in das Sprint Backlog Einzug findet.

Eine explizite Frage nach dem „Warum ist dieser Sprint wichtig?“, die vor den beiden anderen Fragen geklärt werden sollte, existiert im Scrum Guide von 2017 nicht. Um das „Warum“ zu klären, sieht der Scrum Guide von 2017 die gemeinsame Erstellung eines Sprintziels (engl. Sprint Goal) durch das Scrum Team vor. Es dient dazu, das Entwicklungsteam [1] in der Frage, "warum es dieses Product Increment erstellt [2]", zu leiten. Ein gemeinsames Ziel erhöht den Fokus im Sprint und steigert die Kohärenz der ausgewählten Arbeit. Es schafft Transparenz und ermöglicht so, während des Sprints die Fortschritte in Bezug auf das Sprintziel zu überprüfen. Das ermöglicht, frühzeitig gegenzusteuern, falls das Sprintziel in Gefahr sein sollte.

Ein gutes Sprintziel lässt den Developern genug Flexibilität in Bezug auf die Funktionalität, die im Sprint implementiert werden soll. In der Realität ist es häufig schwierig, ein gutes Sprintziel zu definieren, auf das die ausgewählten Product Backlog Items einzahlen. Manche Teams neigen dazu, zuerst Product Backlog Items für den Sprint auszuwählen und erst danach das Sprintziel zu definieren. Hier ist es schwierig, thematisch wenig oder gänzlich unzusammenhängende Product Backlog Items unter einem gemeinsamen Ziel zusammenzufassen und der Fokus geht verloren.
Die Änderungen im Scrum Guide 2020 sollen dabei helfen, frühzeitig im Planning gemeinsam ein Sprintziel zu entwickeln.

Was ist neu?

Obwohl das Wort Sprintziel 27-mal im Scrum Guide von 2017 auftaucht und definitiv einen wichtigen Beitrag bei der Erstellung von Valuable Done Increments liefert, war das Sprintziel kein Bestandteil einer Rolle, eines Events oder Artefakts. Im neuen Scrum Guide wurde das Sprintziel deutlich aufgewertet. Der Scrum Guide von 2020 enthält nun ein Commitment (Verpflichtung, Versprechen) des Sprintziels für das Sprint Backlog (siehe Artikel zu den drei Commitments [3]). Dieses Commitment schafft Transparenz und den Fokus darauf, das Sprintziel zu erreichen. Das gemeinsame Ziel stärkt den Teamzusammenhalt und sorgt für eine höhere Kohärenz der Product Backlog Items.

Um das Scrum Team dabei zu unterstützen, ein geeignetes Sprintziel zu definieren, wurde eine weitere Frage in das Sprint Planning aufgenommen, die gleich zu Beginn beantwortet werden sollte: „Warum ist dieser Sprint wertvoll?“. Die Antwort darauf gibt dem Sprint einen Sinn – ein (Sprint-)Ziel. Durch das Auseinandersetzen mit der Frage nach dem "Warum" wird eine Fokussierung auf die Generierung von Value für die Stakeholder erreicht. Die zu bearbeitenden Product Backlog Items des nächsten Sprints werden nach ihrem Wert für den Kunden ausgewählt und zahlen auf das Sprintziel ein. Dadurch wird ein Bauen von goldenen Henkeln, die der Kunde nicht benötigt, vermieden.

Der Product Owner legt dem Scrum Team zu Beginn des Sprint Plannings dar, wie er oder sie den Wert und Nutzen des Produkts für die Stakeholder durch diesen Sprint steigern möchte. Aus diesen Informationen kann das Scrum Team, das nun gemeinsam die Verantwortlichkeit trägt, jeden Sprint ein wertvolles, nützliches Inkrement zu erstellen, ein Sprintziel erarbeiten, auf das sich die Developer committen können.

Sprintziele sind logische Schritte zur Erreichung des Product Goals [4], das ebenfalls neu hinzugekommen ist und das einen Fokus auf mehrere Sprints ermöglicht.

Fazit

Endlich gibt es ein klares Commitment für das Sprintziel und das explizite Fragen nach dem „Warum ist dieser Sprint wertvoll“ kann dabei helfen, ein gutes Sprintziel zu finden und kohärente Product Backlog Items auszuwählen, die einen Value für die Stakeholder erzeugen.

Bei Scrum Teams, bei denen bisher zuerst die Product Backlog Items für den Sprint ausgewählt und erst danach nach einem passenden Sprintziel gesucht wurde, kann das Fragen nach dem "Warum" helfen, thematisch wenig zusammenhängende Product Backlog Items im Sprint zu verhindern.

[1] Seit dem neuen Scrum Guide von 2020 gibt es den Begriff Entwicklungsteam nicht mehr. Stattdessen wird der Begriff Developer verwendet.

[2] Quelle: Scrum Guide 2017 Deutsche Version: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf, zuletzt abgerufen am 17.12.2020.

Der Autor dieses Artikels

Martin Blersch

Agile Coach