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.

 

Download PDFDownload PDF

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.

 

Wir empfehlen zum Thema Scrum
3 x 4 Stunden
07.11.2024
1.295,00,-
User Story Mapping - Die Nutzer im Blick mit der Produkt-Landkarte

Stellen Sie Kundenanforderungen – ohne endlose Dokumentationen – strukturiert dar und behalten Sie mit diesem Seminar die Kontrolle über den gesamten Entwicklungsprozess. Mit vielen Praxisübungen und direkt anwendbar. Mehr Infos

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 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.

Scrum-Projekte planen mit System


Gleich kostenlos weiterlesen!

  • Zum Newsletter anmelden und diesen Artikel freischalten

  • Jede Woche neue Inhalte, Tipps und Tools per E-Mail
Gratis Newsletter bestellen & sofort weiterlesen

 

Hiermit melde ich mich zum Newsletter an. Ich habe die Datenschutzrichtlinien gelesen und akzeptiere diese. Ihre Daten nutzen wir ausschließlich zum Newsletter-Versand und der Messung von Öffnungs- und Klickraten. Sie können sich jederzeit abmelden, indem Sie auf den Link in der Fußzeile unserer E-Mails klicken. Informationen zu unserem Datenschutz finden Sie hier.

Fortsetzungen des Fachartikels

Teil 1:
Besonderheiten und Voraussetzungen

Genau wie in traditionellen Projekten nimmt auch in Scrum die Planung eine zentrale Rolle ein. Allerdings wird dort auf eine längere vorgelagerte Planungsphase verzichtet, stattdessen findet die Planung größenteils parallel zur Entwicklung statt.