Scrum-Projekte planen mit System

Teil 2: Vorgehen in der Praxis
Im ersten Teil stellte Dominik Maximini ein Vorgehen vor, um Scrum-Projekte strukturiert zu planen und zeigte Fehler auf, die dabei häufig in der Praxis gemacht werden. In diesem zweiten und abschließenden Teil stellt er die einzelnen Planungsschritte an einem Praxisbeispiel im Detail vor.

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

  1. Die Geschäftsführung definiert mit dem Product Owner 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 Backlog ein (strategische Planung).
  5. 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.
  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 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).
  9. In der Retrospektive wird ermittelt, wie das Team noch effizienter arbeiten kann (strategische Planung).
Tabelle 1: Ergebnisse und Verantwortlichkeiten der strategischen und operativen 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

Anzeige
Der vollständige Artikel ist für Abonnenten frei zugänglich.
Artikel kaufen (4,50 €)
  • 10 Seiten Praxiswissen
  • PDF-Download
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen Online-Zugriff auf alle Artikel, Methoden und das Glossar
Tech Link