Keine Frage stellt Product Owner vor eine größere Herausforderung als:
„Wie soll das Product Backlog geordnet werden?“
Diese Frage habe ich mir tagtäglich in meiner Arbeit als Product Owner gestellt, sie wird mir in jedem Scrum Training gestellt und ich höre sie in fast jedem Coaching. Dies ist nicht weiter verwunderlich. Auf der einen Seite macht die Antwort auf die Frage den Kern der Product-Owner-Verantwortung aus.
Der Scrum Guide hält diese unmissverständlich fest:
„Der Product Owner ist verantwortlich, die Reihenfolge der Product-Backlog-Einträge festzulegen.“
Auf der anderen Seite gibt der Scrum Guide keine Anleitung darüber, wie Product Owner entscheiden sollen, welche Einträge oben im Product Backlog stehen und welche unten. Der Guide hält nur fest, dass die Entscheidung, wie der Wert für das Produkt optimiert werden soll, an der Reihenfolge des Product Backlogs abzulesen ist:
„Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs sowie durch das überprüfbare Inkrement beim Sprint Review sichtbar.“
Ich hatte das Glück, dass ich in meiner Arbeit als Product Owner zwei Mentoren hatte, die mir unterschiedliche Techniken zeigten, die Gründe für meine Entscheidungen hinterfragten und mir neue Perspektiven auf die Situation anboten. Über die Jahre habe ich auch viele Schulungen bei führenden Experten und Autoren besucht, um von ihnen zu lernen, wie Product Owner entscheiden. Ich war bei Björn Jensen, Jeff Patton, Chris Lukassen und Jeff Gothelf in Schulungen und habe eine mehrwöchige Product-Manager-Ausbildung bei der Product School gemacht.
Egal, wie viele neue Ideen und Techniken ich lerne, am Ende geht es immer um drei grundlegende Kriterien:
- Kriterium 1: Wie groß ist der Wert für die Stakeholder?
- Kriterium 2: Wie groß ist der Wert für die Nutzer?
- Kriterium 3: Wie groß ist der Aufwand?
Die Entscheidung, an welcher Stelle des Product Backlogs ein Eintrag steht, entsteht durch die Abwägung dieser drei Kriterien. Die Ordnung des Product Backlogs ist dann der Ausdruck des Wertes für das Produkt.
Lass uns die drei Kriterien nun im Details betrachten und ich gebe dir Anleitung, wie du sie direkt in deine Entscheidungen miteinbeziehen kannst.
Kriterium 1: Wie groß ist der Wert für die Stakeholder?
Wert hängt von der Perspektive ab.
Drei Perspektiven sind hierbei entscheidend: Wert für Stakeholder, Kunden und Nutzer.
Ich unterscheide hierbei zwischen Stakeholdern, Kunden und Nutzern wie folgt:
- Stakeholder: Personen, die ein Interesse oder einen Einfluss auf das Produkt haben.
- Kunden: Personen, die entscheiden, ob das Produkt gekauft wird.
- Nutzer: Personen, die das Produkt nutzen.
Eine einfache Möglichkeit, den Wert für Stakeholder oder Kunden einzuschätzen, ist ein Buy-a-Feature-Workshop.
Der Workshop besteht aus vier Schritten:
- Die Product-Backlog-Einträge, die zum Kauf bereitstehen, werden mit einem Preis versehen und zu einer Liste zusammengefasst.
- Das Spielgeld wird gleichmäßig unter den Stakeholdern aufgeteilt.
- Die Stakeholder kaufen die Product-Backlog-Einträge, welche für sie am wichtigsten sind. Jeder Eintrag kann einmal gekauft werden. Die Stakeholder können beim Kauf ihr Geld zusammenlegen.
- Wenn das Geld ausgegeben ist, spiegeln die gekauften Einträge der Liste wider, welche Product-Backlog-Einträge den Stakeholdern gemeinschaftlich wichtig sind.
Damit die Stakeholder zusammenarbeiten müssen, sollten sie insgesamt nur so viel Geld erhalten, dass sie nur die Hälfte der Product-Backlog-Einträge kaufen können. Einige Einträge sollten so teuer sein, dass kein einzelner Stakeholder sie allein erstehen kann.
Nachdem die Stakeholder ihren „Einkauf“ beendet haben, also alles Geld ausgegeben wurde, lass dir ihre Kaufentscheidungen erklären. Du möchtest erfahren, was sie zu ihrer Wahl motiviert hat. Stelle dazu einige Fragen: „Warum hast du dieses Feature den anderen Features vorgezogen? Warum warst du bereit, auf ein Feature zu verzichten, um dich mit jemand anderem zusammenzutun und ein teureres Feature zu kaufen? Was waren die Gründe hinter deiner Auswahl?“
Dieser Workshop hilft dir, mehr darüber zu erfahren, wie die Stakeholder oder Kunden über dein Produkt denken und wie es zur Strategie des Unternehmens beiträgt. Mit den Informationen der Stakeholder, die du aus dem Buy-a-Feature-Workshop erhältst, kannst du die Einträge deines Product Backlogs nach Stakeholder-Wert priorisieren.
Da der Wert für Stakeholder nicht gleich dem Wert für Nutzer ist, gilt es, diese gesondert zu betrachten.
Kriterium 2: Wie groß ist der Wert für die Nutzer?
Hierzu gibt es viele Möglichkeiten:
Erhebe, wie häufig und lange die Nutzer das Produkt und die bestehenden Features bereits nutzen. Erfasse durch Umfragen, wozu sie das Produkt oder bestimmte Features nutzen. Oder befrage sie direkt durch Interviews.
Mehr darüber, wie ich Nutzerinterviews durchführe, kannst du in diesen beiden Beiträgen nachlesen:
- Kein UX-Designer im Team? Mit diesen 3 einfachen Techniken kann dein Scrum Team noch heute mit UX-Research beginnen
- 3 harte Lektionen, die ich beim Interviewen von Kunden gelernt habe
Zusammengefasst geht es bei einem Interview darum, herauszufinden, welche Probleme, Schmerzen, Bedürfnisse, Wünsche und Motivationen die Nutzer haben. Halte die Einsichten aus den Interviews in Proto-Personas fest. Mehr zu Proto-Personas kannst du hier nachlesen.
Das Problem bei der Bedürfnisanalyse?
Bedürfnisse sind schwer quantifizierbar. Ist das Bedürfnis eines Nutzers, informiert zu sein, wichtiger als sein Bedürfnis, Geld zu verdienen? Ist das Bedürfnis, Geld zu verdienen, wichtiger als Zeit zu sparen? Ist das Bedürfnis, Aufwand zu vermeiden, wichtiger als motiviert zu werden?
Deshalb kombiniere ich die Einsichten über die Bedürfnisse der Nutzer mit der „Elements of Value“-Pyramide. In dieser Pyramide halten Bain & Company fest, welche Bedürfnisse Produkte erfüllen können.
Hierbei sollte die Optimierung des Produkts mit den funktionalen Elementen beginnen. Daher bilden diese Elemente das Fundament der Pyramide. Bevor Nutzer den weitreichenden Wert des Produkts wahrnehmen können, muss das Produkt zunächst Wert in Form von Funktionalität bieten, d. h. einen funktionalen Wert liefern. Das Produkt sollte die Probleme der Nutzer lösen und ihre zentralen Bedürfnisse erfüllen. Dies kann z. B. durch einfache, ansprechende, zeitsparende, kostengünstige oder praktische Lösungen geschehen. Nachdem das Produkt den Nutzern einen funktionalen Nutzen bietet, kann es ihnen auch einen emotionalen oder lebensverändernden Wert liefern. Diese beschreiben die oberen Ebenen der Pyramide.
Die Zuordnung zwischen Bedürfnis und Wert-Element in der Pyramide gibt dir ein Kriterium für die Priorisierung der Einträge des Product Backlogs. Steht etwa die Entwicklung des Produkts noch am Anfang, dann haben funktionale Werte und die dazu korrespondierenden Bedürfnisse der Nutzer eine hohe Gewichtung. Wenn das Produkt bereits am Markt etabliert ist, dann sollten die lebensverändernden Werte höher gewichtet werden als die funktionalen.
Wert für die Stakeholder und Wert für die Nutzer stehen immer in Relation zum Aufwand der Entwicklung. Deshalb lautet das letzte Kriterium:
Kriterium 3: Wie groß ist der Aufwand?
Beim Schätzen des Aufwands hat sich bewährt, dass die Schätzungen relativ sind und in abstrakten Maßeinheiten geschehen.
Relativ bedeutet nicht, zu schätzen, wie viele Stunden Arbeit dieser Eintrag im Product Backlog erfordert, sondern, ob er mehr oder weniger Arbeit als ein bereits umgesetzter Eintrag benötigt. Ist die Maßeinheit eine abstrakte Größe, wie die Fibonacci-Folge, T-Shirt-Größen oder Gummibären, besteht weniger die Gefahr, dass die Schätzung als Deadline aufgefasst wird und deshalb implizit Risikoaufschläge gemacht werden.
Eine bewährte Methode, um eine große Anzahl von Einträgen des Product Backlogs zu schätzen, stellt die Magic Estimation dar.
Folgende Schritte sind dazu nötig:
- Die Zahlen der Fibonacci-Folge bis 21, ergänzt durch ein Fragezeichen, bilden mögliche Größenwerte (1, 2, 3, 5, 8, 13, 21, ?).
- Einem Product-Backlog-Eintrag wird gemeinschaftlich eine Größe zugeordnet und dient als Referenz für die Zuordnung der restlichen Einträge.
- Die verbleibenden Product-Backlog-Einträge werden unter den Entwicklern verteilt.
- Die Entwickler ordnen jedem ihrer Product-Backlog-Einträge eine entsprechende Größe in Relation zum Referenzeintrag zu. Verstehen sie einen Eintrag nicht, wird ihm das Fragezeichen zugeordnet. Während des Zuordnens sprechen sie sich nicht mit den anderen Beteiligten ab.
- Nachdem alle Product-Backlog-Einträge zugeordnet wurden, schauen sich die Entwickler alle Zuordnungen an und ordnen ihnen eine neue Größe zu, falls sie der Wahl der zugeordneten Größe nicht zustimmen.
- Lässt sich einem Product-Backlog-Eintrag keine eindeutige Größe zuordnen, wird ihm der größere der beiden Werte zugeordnet. Wurde einem Eintrag ein Fragezeichen zugeordnet, bedarf es weiterer Klärung unter Einbezug des Product Owners, bis ihm eine eindeutige Größe zugeordnet werden kann.
Das Resultat ist ein in Relation zum Referenzeintrag geschätztes Product Backlog. Wie viel Aufwand ein Eintrag des Product Backlogs ist, dient als drittes Kriterium für die Ordnung des Product Backlogs.
Zum Schluss eine Warnung:
Die Reihenfolge des Product Backlogs zu bestimmen, ist eine komplexe Entscheidung.
Diese sollte nicht leichtfertig auf eine Zahl reduziert werden.
Leider sehe ich häufig, dass mit den Kriterien nur der „Return on Investment“ berechnet wird. Also ROI = Wert/Aufwand.
Mit unseren Kriterien würde die Formel dann lauten:
ROI = (Wert für Stakeholder + Wert für Nutzer) / Aufwand
Ich halte es für keine gute Idee, die Entscheidung auf diese Formel zu reduzieren.
Ja, mit den Kriterien können wir die Einträge des Product Backlogs nach unterschiedlichen Gesichtspunkten priorisieren. Aber die Kriterien sollen uns nur als Ausgangspunkt für unsere Entscheidung dienen. Sie dienen als Datenbasis, welche wir bei der endgültigen Entscheidung heranziehen können. Die Daten entscheiden aber nicht für uns! Denn es gibt immer noch Überraschungen, an die wir nicht gedacht haben und Informationen, die wir nicht haben. Das ist das Wesen komplexer Arbeit.
Aber die Reduktion auf eine Zahl suggeriert genau das Gegenteil.
Diese eine Zahl verschleiert die Ungewissheit in der Entwicklung von Produkten. Sie impliziert, dass wir alle Informationen haben, es keine Überraschungen mehr gibt und wir eine perfekte Entscheidung nur anhand der vorliegenden Daten treffen können. Aber dies ist wohl nie der Fall!
Ankündigung: Scrum.org hat heute ein neues Skill-Training gelauncht!
Falls du dich bisher wenig mit dem Product-Backlog-Management beschäftigt hast und praktische Techniken zur Erstellung, Verfeinerung und Ordnung des Product Backlogs erlernen möchtest, dann lege ich dir den Besuch dieses Trainings ans Herz.
Hier findest du weitere Details zum „Professional Scrum Product Backlog Management Skills“-Training.
Es handelt sich um den Grundlagenkurs im Product-Backlog-Management – speziell für alle, die nach Wegen suchen, das Product Backlog transparenter zu gestalten, die Bedürfnisse von Stakeholdern zu erfassen und effektiver mit Stakeholdern zu kommunizieren.