Der erste Teil beschrieb kurz die neun Planungsschritte in Scrum 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
- Die Geschäftsführung definiert mit dem Product Owner die Produktvision (strategische Planung).
- Der Product Owner definiert die Releaseziele zusammen mit den Stakeholdern (strategische Planung).
- Der Product Owner definiert die Sprintziele zur Erreichung des aktuell anstehenden Releaseziels (strategische Planung).
- Der Product Owner trägt die benötigten Features im Product Backlog ein (strategische Planung).
- In der ersten Hälfte des Sprint Plannings stellt der Product Owner dem Team 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.
- In der zweiten Hälfte des Sprint Plannings plant das Team präzise auf Taskebene, wie es sein Sprintziel erreichen möchte (operative Planung).
- 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).
- Am Ende des Sprints wird im Sprint Review 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).
- In der Retrospektive wird ermittelt, wie das Team noch effizienter arbeiten kann (strategische Planung).
| Planungsartefakte | Verantwortlich | |
|---|---|---|
| Strategische Planung |
Produktvision Releaseplanung Sprintziele |
Product Owner |
| Operative Planung |
Sprintplanung tägliche Anpassung dieser Planung an die aktuellen Gegebenheiten |
Entwicklungsteam |
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.
Der recht hohe Aufwand für die Erstellung der Produktvision führt zu einem im Umfang kleinen, aber sehr wertvollen Ergebnis: Ein paar Zeilen Text, die eine "Produktvision für Kopf und Herz" bieten. So gibt es bei der Beispiel AG ein Teilprojekt, welches sich mit der Innenbeleuchtung der Fahrgastzelle beschäftigt. Für dieses Teilprojekt könnte die Produktvision beispielsweise lauten: "Wir erleuchten unsere Kunden." Kurz, prägnant und trotzdem ein starker Bezug zum Produkt inklusive einer emotionalen Komponente.
Problematisch ist es, wenn – wie im Beispielprojekt – keine Produktvision existiert. Ebenso schädlich ist es, wenn ohne ausführliche Recherche eine Vision "aus dem Bauch heraus" definiert wird – diese ist zwar oft wohlklingend, aber leider nicht fundiert. Die gesamte strategische Planung bezieht sich dann möglicherweise auf ein falsches Ziel – bzw. bei einer fehlenden Produktvision auf gar kein Ziel. Da dieses Risiko erst langfristig eintritt, fällt es auch anfangs nicht auf. Bleiben wir beim obigen Beispiel: Wenn die Marktanalyse fehlt, entgeht der Beispiel AG möglicherweise, dass die Kunden gar nicht "erleuchtet" werden wollen und der Wettbewerb ganz andere Schwerpunkte setzt, z.B. die Konzentration auf akustische Faktoren in der Fahrgastzelle. So schön die Vision dann auch sein mag – am Ende der Entwicklung wird der Kunde das Produkt vermutlich ablehnen.
Es gibt nur einen Product Owner
Ein weiteres Problem entsteht, wenn es mehrere Product Owner für ein Produkt gibt. Das steht zwar im Widerspruch zu…
