Wie entsteht eigentlich ein Product Backlog? Und was muss ein Product Owner über Requirements Engineering wissen?
Im Scrum Guide wird die Rolle des Product Owners (PO) als diejenige definiert, die den wirtschaftlichen Erfolg des Scrum Teams verantwortet. Wichtigstes Steuerungsinstrument ist dabei das sogenannte Product Backlog, welche die umszusetzenden Funktionen & Eigenschaften des Produktes enthält. Der Product Owner ist zwar der „Herrscher“ über das Product Backlog (bspw. durch das Festlegen der Umsetzungsreihenfolge), an dessen inhaltlicher Gestaltung soll aber das gesamte Scrum Team mitwirken.
Zumindest der Scrum Guide erläutert jedoch nicht, wie das Product Backlog initial entsteht. Was muss ich als Product Owner tun in Vorbereitung des ersten Sprints?
Fakt ist: In das erste Sprint Planning muss ich als Product Owner mit einem gefüllten Product Backlog gehen, welches Product Backlog Items für die (mind.) nächsten 2 Sprints enthält (z.B. User Stories). Und die Einträge müssen „ready for implementation“ sein. Soll heißen: die Umsetzung der Product Backlog Items könnte sofort beginnen. Das bedeutet:
- Die Product Backlog Items wurden in eine aus Sicht des PO sinnvolle Reihenfolge gebracht
- das Development Team hat die Product Backlog Items inhaltlich verstanden
- das Development Team hat die Product Backlog Items geschätzt
- Die Product Backlog Items sind klein genug, um in einem Sprint vollständig umgesetzt zu werden
- es gibt keine gegenseitigen Abhängigkeiten zwischen den Product Backlog Items
Doch wie fange ich als PO an?
Meine Empfehlung: Nutze die bestehenden Mittel und Werkzeuge, die uns das Requirements Engineering zur Verfügung stellt (siehe auch IREB)!
Wenn ich als PO in einem Projekt neu starte, dann durchlaufe ich i.d.R. die folgenden Schritte.
- Ich führe führt eine Stakeholderanalyse durch und ermittle, welche Menschen als Quelle für Anforderungen in Frage kommen.
- Ich lerne die Sprache des Kunden und erstelle einen Domänenklassenmodell , welches im Projektverlauf verfollständigt wird-> Statische Perspektive
- Ich lerne die Soll-/ oder Ist-Abläufe des Kunden kennen und erstelle Ablaufdiagramme unter Verwendung der Ergebnisse aus den vorher angegebenen Schritte-> Funktionale Perspektive
- Bei komplexeren Domänenklassen kann es sinnvoll sein, die Verhaltensperspektive gesondert zu betrachten und Verhaltensdiagramme zu erstellen, insbesondere bei reaktiven System (bspw. Oberflächen, HMI etc.)
- Ich dokumentiere das erworbene Wissen (nur soweit erforderlich)
- Ich vermittle das Wissen in Workshops (Grooming Session, Estimation Meeting, Sprint Planning) dem gesamten Scrum Team
- Gemeinsam mit dem Team leite ich sinnvolle Product Backlog Items ab, die bereits in der Anfangsphase einen Nutzen für den Kunden stiften
- Ich stelle das Product Backlog auch dem Kunden vor, um ggf. Feedback und Hinweise einzusammeln und das Product Backlog anzupassen.
All dieses Wissen muss ich als Product Owner meinem Development Team vermitteln. Diese Kernaufgabe impliziert, dass der Product Owner auch ein Requirements Engineer ist – nicht der einzige, aber der wichtigste im Scrum Team.
Resumee: Als Product Owner muss ich das Handwerkszeug eines Requirements Engineers kennen und anwenden können.[/vc_column_text][/vc_column][/vc_row]