Von der Produktvision zum Product Backlog

Wahrscheinlich kennen Sie die Herausforderung, von einer Grobidee zu einem Product Backlog zu kommen. Nun, wie könnte ein systematisches Vorgehen aussehen?

Ich empfehle, mit der Produktvision zu beginnen. In den Dimensionen Zeit / Kosten / Visionserfüllung muss die Balance gefunden werden, mit dem Ziel, das bestmögliche Produkt zu erstellen.

Kerneigenschaften der Produktvision

• sie ist akzeptiert, gemeinsam erarbeitet
• sie ist stabil und klar formuliert
• sie ist motivierend und breit formuliert (Freiraum lassend)
• sie ist kurz und bündig

Die Produktvision soll stabil sein, das Product Backlog jedoch ist dynamisch. Was heisst das? Das heisst, die Vision soll über mehrere Sprints stabil sein, und je nach Anforderung alle 3 oder 6 Monate angepasst werden. So kann während der Sprints auf die Vision hingearbeitet werden (es werden nur Dinge abgearbeitet, die der Vision dienen!). Das P/B jedoch kann sich vor / während / nach dem Sprint ändern, ist eben dynamisch (Priorisierung und Schätzungen anpassen, Stories rein / raus etc.).

Output der Produktvision

• Wer ist der Kunde, wer ist der Benutzer?
• Welche Bedürfnisse werden durch das Produkt befriedigt?
• 10 kritische Produkteigenschaften?
• Stellung zu bestehenden Produkten
• Zeit- und Kostenrahmen
• Geschäftsmodell
• Stückpreis und -kosten

Wenn ich mir obige Punkte ansehe, könnte ich mir vorstellen, diesen Output auf eine Kartonschachtel zu drucken und diese Schachtel mit dem Produkt drin in die Software Abteilung des Kaufhauses am Ort zu tragen – vielleicht fühlt sich ein Kunde davon angesprochen?

Zum Unterschied Kunde / Benutzer: in einem größeren Unternehmen wäre die Abteilung, die die Software einkauft und installiert der Kunde, jedoch ist der Endanwender an dem einzelnen PC der Benutzer. So ist es dem Benutzer egal, ob die Software-Einstellungen zentral verwaltet werden können (Hauptsache „es läuft“), während dieses Feature dem Kunden durchaus wichtig sein kann.

Wie viel Zeit wird in die Erstellung der Produktvision investiert? Gerade genug Zeit, um obige Punkte zu erhalten. Auch bei der Produktvision gilt: sie kann nicht im Vorfeld endgültig erstellt werden, sie wird sich dynamisch verändern, dies aber im 3 oder 6 Monate Rhythmus. Es lohnt sich also nicht, ein Big Upfront Planning zu machen (wie immer bei Scrum :-)).

Und nun, um dem Titel des Beitrags gerecht zu werden, wie kommen wir von der Produktvision zum Product Backlog? Indem wir die 10 kritischen Produkteigenschaften nehmen und als Stories in das Product Backlog schreiben. Wenn der Detaillierungsgrad noch nicht passt, wird die höchstpriore Story einfach in 3-5 weitere Stories runter gebrochen und diese neuen Stories auch gleich priorisiert. Nun gehen Sie so weiter vor, bis Sie max. 100 Stories in Ihrem initialen Product Backlog haben. Das sollte eigentlich klappen!

Produktplanungsstrategie

• das Produkt soll einfach gehalten werden, also keine Eierlegende Wollmilchsau sein → „Small is beautiful“. Lieber schnell an den Markt und damit früh ein Feedback vom Markt einholen.
• mit Versionen arbeiten, inkrementelle Auslieferung
• fester Innovationsrhytmus (Zeit ist Time-boxed), z.B. alle 3 Monate eine neue Version veröffentlichen

Ich hoffe, Sie als Product Owner mit diesen Informationen ein wenig näher zum idealen Produkt gebracht zu haben.