Der erste Teil beschrieb kurz die neun Planungsschritte in ScrumScrumScrum ist ein Rahmenwerk zur Entwicklung, Lieferung und Wartung komplexer Produkte, das auf eine leichtgewichtige, iterativ-inkrementelle Vorgehensweise in kurzen Lernschleifen setzt. Das Rahmenwerk definiert Rollen, Artefakte (Planungs- und Arbeitsergebnisse) und Ereignisse (Events) sowie das Zusammenspiel dieser drei Elemente. Scrum ist keine Prozessvorgabe, sondern stellt als Rahmenwerk sozusagen ein Spielfeld mit Regeln auf – die konkrete Arbeitsweise können die Anwender von Scrum innerhalb dieses Rahmens selbst definieren. und zeigte die wesentlichen Faktoren auf, die es dabei zu beachten gilt. Außerdem beleuchtete der Beitrag die Aspekte der strategischen und operativen Planung und ging darauf ein, welche Fehler bei der Planung häufig gemacht werden. Dieser zweite und abschließende Teil stellt die einzelnen Planungsschritte nun detailliert an einem Praxisbeispiel vor.

Neun Planungsschritte in Scrum

1. Die Geschäftsführung definiert mit dem Product OwnerProduct OwnerProduct Owner ist eine der drei Verantwortlichkeiten (bis 2020 Rollen) bei Scrum . Der Product Owner ist verantwortlich für das Product Backlog . die Produktvision (strategische Planung).
2. Der Product Owner definiert die Releaseziele zusammen mit den Stakeholdern (strategische Planung).
3. Der Product Owner definiert die Sprintziele zur Erreichung des aktuell anstehenden Releaseziels (strategische Planung).
4. Der Product Owner trägt die benötigten Features im Product BacklogProduct BacklogProduct Backlog ist bei Scrum die Liste aller Anforderungen für ein zu erstellendes Produkt. ein (strategische Planung).
5. In der ersten Hälfte des Sprint Plannings stellt der Product Owner dem TeamTeamEin Team ist eine Gruppe von Personen, die gemeinsam eine Aufgabe erledigen sollen. Meist besteht innerhalb des Teams keine formelle Hierarchie. Grundidee der Arbeit im Team ist das Zusammenwirken ergänzender Fähigkeiten und Fertigkeiten der Teammitglieder, um ein Ergebnis zu erreichen, das für jedes einzelne Teammitglied allein nicht leistbar gewesen wäre. diese Ziele vor. Das Team wählt sich eine Untermenge an Features aus dem Product Backlog aus, die es umsetzen will (operative Planung). Ggf. werden die Sprintziele nochmals angepasst oder Features im Product Backlog geändert.
6. In der zweiten Hälfte des Sprint Plannings plant das Team präzise auf Taskebene, wie es sein Sprintziel erreichen möchte (operative Planung).
7. Die Planung wird täglich, spätestens während des Daily Scrums, überprüft. Abweichungen werden an den ScrumMaster adressiert und an den Product Owner kommuniziert (operative Planung).
8. Am Ende des Sprints wird im Sprint ReviewSprint ReviewIm Sprint Review prüft das Scrum Team – ggf. mit weiteren, vom Product Owner eingeladenen, Stakeholdern – am Ende eines Sprints den erzielten Fortschritt und erarbeitet die Grundlagen für das folgende Sprint Planning . Der Scrum Guide betont, dass das Sprint Review informellen Charakter hat und nicht der Berichterstattung über den Projektstatus dient. das Produkt inspiziert. Hier planen Product Owner, Entwicklungsteam und Stakeholder gemeinsam, welche Veränderungen im Product Backlog nötig sind, um das Releaseziel zu erreichen (strategische Planung).
9. In der Retrospektive wird ermittelt, wie das Team noch effizienter arbeiten kann (strategische Planung).

Wie bereits im ersten Teil erwähnt, wiederholen sich diese Schritte regelmäßig für jeden Sprint. Allerdings müssen dabei nicht immer alle Planungsartefakte von Grund auf neu erstellt werden. Zum Beispiel ändern sich Produktvision und Releaseziel wesentlich seltener als die Sprintziele. Dennoch überprüft der Product Owner regelmäßig in jedem Sprint ihre Gültigkeit.

Praxisbeispiel

Das Projekt der "Beispiel AG" stammt aus dem Automobilbereich und beschäftigt sich mit der integrierten Softwareentwicklung (also Software, die Hardware steuert). Dabei arbeiten zehn Scrum-Teams mit insgesamt ca. siebzig Entwicklern in einem fortlaufenden Projekt. Die Budgets werden jeweils für ein Release freigegeben, die Releasezyklen betragen drei Monate. Das Produkt besteht aus Server-, Client-, Datenbank- sowie Endgerätebestandteilen und gliedert sich in fünf Teilprodukte auf, die jeweils von einem Product Owner und zwei Entwicklungsteams betreut werden. Diese fünf Product Owner kümmern sich gemeinsam mit weiteren Produktmanagern um die strategische Planung. Das Unternehmen ist noch in der Scrum-Einführungsphase und lernt jeden Sprint dazu.

Die Planungsschritte im Detail

Die oben aufgeführten Schritte sehen wir uns nun etwas genauer an. Neben dem eigentlichen Ziel jedes einzelnen Planungsschritts und der Anwendung bei der Beispiel AG betrachten wir auch die gängigsten Stolperfallen inklusive der Lösungsvorschläge.

1. Die Geschäftsführung definiert mit dem Product Owner die Produktvision

Dies geschieht normalerweise zu Projektbeginn oder die Vision ist in Weiterentwicklungsprojekten bereits vorhanden. Im Regelfall bringt die Geschäftsführung alle relevanten Stakeholder inklusive des Product Owners an einen Tisch und erarbeitet gemeinsam mit diesen eine Produktvision. Dafür müssen selbstverständlich umfassende Analyseaufgaben vorangehen, um den Vergleich mit dem Wettbewerb, Marktanforderungen, SWOT-Diagramme und ähnliches vorliegen zu haben. Diese Daten bereitzustellen ist Aufgabe des Product Owners.