In der Theorie schaut ja alles ganz einfach aus: Der Product Owner bastelt den ersten Product Backlog, lässt sich vom Team eine Einschätzung des Aufwands geben, priorisiert die User Stories und schon ist das Produkt so gut wie fertig. Wie gesagt, so steht es im Lehrbuch. Aber wie sieht das ganze in der Praxis aus und wie wird es organisiert?
In der Regel fällt irgendwann einmal der Entschluss ein neues Projekt anzugehen und es wird ein Verantwortlicher dafür bestimmt. Das ist normalerweise der zukünftige Product Owner. Seine erste Aufgabe ist die Formulierung der Zieldefinition und die Erstellung der ersten Version des Product Backlogs.
- Er wird im ersten Schritt nicht umhinkommen eine Grobversion zunächst selbst zu erstellen. Dazu kann er sich bei Bedarf mit Fachleuten, also Entwicklern etc. besprechen. Das Ergebnis ist die Grundlage für den nächsten Schritt.
- Zeit für ein erstes Meeting. Dazu versammelt der Product Owner alle verfügbaren bzw. notwendigen Fachleute. Ziel ist es, eine erste realistische Aufwandseinschätzung für die User Stories zu erhalten. Je nach Umfang des Projektes kann dieses Meeting mehrere Stunden in Anspruch nehmen.
- Sobald der erste, realistische Product Backlog steht, kann der Product Owner die Kosten des Projektes einschätzen. Kommt Anschließend das Go vom Management, kann es losgehen.
- Spätestens jetzt kommt der Scrum Master ins Spiel. Der Product Owner muss in Zusammenspiel mit ihm dafür sorgen, dass der folgende Prozess korrekt, sprich also Scrum-konform aufgesetzt wird.
- Jetzt gilt es das passende Team zusammenzustellen. Dessen erste Aufgabe: Noch ein Product Backlog Meeting, dieses mal aber mit den konkret Beteiligten, also den Machern des Projekts. Ziel ist es die Aufwandschätzung nochmals zu optimieren, gegebenenfalls die User Stories zu ergänzen und zu präzisieren.
- Nun muss der Product Owner die User Stories priorisieren und damit die Grundlage für das erste Sprint Planning schaffen.
Im nächsten Beitrag schauen wir uns an, wie ein Product Backlog inhaltlich aussieht.