Der größte Fehler bei der Priorisierung des Product-Backlogs?
Bauchgefühl.
Und nicht, weil Bauchgefühl schlecht ist, sondern, weil es dich angreifbar macht.
Versteh mich nicht falsch: Dein Bauchgefühl, deine Erfahrung, deine Expertise, dein Gespür und deine Intuition sind die wichtigsten Werkzeuge eines Product-Owners. Aus Stakeholder-Sicht sind das aber nur Meinungen. Und wenn Meinungen auf Meinungen prallen, gewinnt entweder die lauteste Stimme oder die deines Chefs. Das Product-Backlog verkommt zum Wunschzettel des Vertriebsleiters.
Leider kenne ich diese Situation nur zu gut.
Was hat mir bisher in dieser Situation geholfen? Du brauchst objektive Kriterien, die deine Prioritäten im Backlog erklären. So offensichtlich, dass du dich nie mehr rechtfertigen musst, warum gerade dieser Eintrag ganz unten im Backlog steht. Heute stelle ich dir drei erprobte Vorgehensweisen vor, wie du Prioritäten im Backlog ermitteln kannst.
Los geht’s:
Schritt #1: Wert bestimmen mit „Buy a Feature“
Das Product-Backlog sollte nach Wert geordnet sein.
Was wertvoll ist, liegt im Auge des Betrachters.
Und was Kunden am wertvollsten finden, sollte das Backlog ordnen – zumindest in der Theorie. In der Praxis sollten wir nicht außer Acht lassen, welche Rolle die Meinung von Stakeholdern am Ende spielt.
Wird der IT-Leiter Entwicklerressourcen bereitstellen, wenn er nicht an das Produkt glaubt?
Wird das PMO das Vorhaben unterstützen?
Wird der Vertrieb das Feature den Kunden vorstellen, wenn er nicht dahintersteht?
Kurzum: Sehen Stakeholder keinen Wert in einem Feature, legen sie dir wahrscheinlich Steine in den Weg.
Eine einfache Möglichkeit, den Wert für Stakeholder einzuschätzen, ist ein Buy-a-Feature-Workshop.
Der Workshop besteht aus vier Schritten:
- Die Einträge des Product-Backlogs, die zum Kauf bereitstehen, werden mit einem Preis versehen und aufgelistet.
- Das Spielgeld wird gleichmäßig unter den Stakeholdern (4 – 6 Personen) aufgeteilt.
- Die Stakeholder kaufen reihum die Einträge, die für sie am wichtigsten sind. Jeder Eintrag kann nur einmal gekauft werden. Die Stakeholder können beim Kauf ihr Geld zusammenlegen.
- Wenn das Geld ausgegeben ist, spiegeln die gekauften Einträge 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 – für mich hat sich sogar nur ein Drittel bewährt – der Product-Backlog-Einträge kaufen können. Die Einträge sollten so teuer sein, dass kein einzelner Stakeholder sie allein kaufen kann. Ein Beispiel: 10 Einträge für jeweils 20 Euro, 6 Stakeholder mit jeweils 15 Euro Investitionskapital.
Nachdem die Stakeholder ihren Einkauf beendet haben, also alles Geld ausgegeben wurde, lass dir ihre Kaufentscheidungen erklären.
Es sollte dir darum gehen, ihre Kaufmotivation zu verstehen. 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?
Vorteile des „Buy a Feature“-Vorgehens:
- Wenn du 10 Features zum Kauf anbietest, solltest du im Anschluss wissen, welche 3 – 5 Features oben im Backlog stehen sollten.
- Die einzelnen Meinungen der Stakeholder aggregieren sich zu Daten.
- Du stehst bei der Diskussion, was am wichtigsten ist, nicht mehr in der Schusslinie. Die Stakeholder diskutieren untereinander, du fungierst lediglich als Moderator.
Jetzt müssen wir noch über etwas Kontroverses sprechen:
In einem Buy-a-Feature-Workshop bewerte ich zunächst alle Features gleich teuer.
Das führt oft zum Aufschrei: „Wenn der Aufwand höher ist, dann muss das Feature doch mehr kosten.“ Das stimmt nicht pauschal. Für Agenturen, die Software einmalig ausliefern, mag das zutreffen. Entwickeln wir jedoch ein Produkt, sind die reinen Entwicklungskosten im Vergleich zu den langfristigen Betriebs- und Folgekosten häufig zweitrangig. Eine kleine Änderung kann großen Nutzen stiften, während ein aufwendiges Feature kaum Wert liefert. Deshalb betrachte ich den Wert zunächst unabhängig vom Aufwand.
Zum Aufwand kommen wir jetzt:
Schritt #2: Aufwandsschätzung mit „Magic Estimation“
Ein großer Fehler bei Aufwandsschätzungen?
Die Entwicklungsarbeit in Euro zu schätzen.
Die Aussage: „Die Entwicklung dieses Features wird uns 45.000 Euro kosten, da 8 Entwickler jeweils 80 Stunden daran arbeiten werden“, ist nur wenig vertrauenswürdig. Softwareentwicklung ist keine Fließbandarbeit. Wir stellen jedes Feature nur einmal her, und deshalb können Entwickler nur schwer einschätzen, wie viel Arbeit am Ende noch nötig sein wird – schlicht und einfach, weil sie es noch nicht gemacht haben.
Besser ist es deshalb, den Entwicklungsaufwand unterschiedlicher Features in Relation zueinander zu stellen.
Eine bewährte Methode hierzu ist „Magic Estimation“. Ziel ist nicht eine exakte Zahl, sondern eine belastbare Sicht der Entwickler auf den relativen Aufwand, die spätere Diskussionen mit Stakeholdern deutlich verkürzt.
Folgende Schritte sind dazu nötig:
- Die Zahlen der Fibonacci-Folge bis 21, ergänzt um ein Fragezeichen, bilden mögliche Größenwerte (1, 2, 3, 5, 8, 13, 21, ?).
- Einem Eintrag des Product-Backlogs wird gemeinschaftlich eine Größe zugeordnet. Er dient als Referenz für die Zuordnung der restlichen Einträge.
- Die verbleibenden Einträge werden unter den Entwicklern verteilt.
- Die Entwickler ordnen jedem ihrer 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 Einträge abgelegt sind, können Teammitglieder andere Schätzungen anpassen, indem sie Einträge zu einem anderen Wert verschieben, wenn sie anderer Meinung sind.
- Für Einträge mit großen Abweichungen oder Unklarheiten folgen gegebenenfalls kurze Diskussionen oder weitere Runden.
- Wurde einem Eintrag ein Fragezeichen zugeordnet, bedarf es weiterer Klärung unter Einbeziehung des Product-Owners, bis ihm eine eindeutige Größe zugeordnet werden kann.
Das Resultat ist ein nach relativem Aufwand sortiertes Product-Backlog, das eine gemeinsame Sicht des Teams auf die Komplexität der Einträge widerspiegelt.
Vorteile des „Magic Estimation“-Vorgehens:
- Eine große Anzahl von Einträgen kann in sehr kurzer Zeit geschätzt werden.
- Die Schätzung basiert auf der kollektiven Einschätzung des gesamten Entwicklungsteams.
- Unklarheiten und Risiken werden früh sichtbar, ohne dass sich das Team in langen Diskussionen verliert.
Jetzt hast du zwei voneinander unabhängige Perspektiven auf das Product-Backlog: den Wert aus Stakeholder-Sicht und den Aufwand aus Sicht der Entwicklung.
Genau diese Trennung macht deine Argumentation schwerer angreifbar.
Schritt #3: Wert und Aufwand gegenüberstellen
Im letzten Schritt kannst du Wert und Aufwand einander gegenüberstellen.
Wie gehen wir dabei vor?
Da die Einträge einmal von den Stakeholdern nach Wert geordnet wurden und einmal von den Entwicklern nach Aufwand, lässt sich dies visuell in einer Matrix veranschaulichen.
Die Matrix besteht aus zwei Achsen:
- Wert: Beschreibt den potenziellen Wert, den die Umsetzung eines Product-Backlog-Eintrags für die Stakeholder liefert.
- Aufwand: Beschreibt den möglichen Aufwand, den die Umsetzung eines Product-Backlog-Eintrags bedeutet.
Zur Ordnung des Backlogs einige generelle Handlungsempfehlungen in der Übersicht:
- Hoher Nutzen, niedriger Aufwand: Diese Einträge sollten oben im Product-Backlog angeordnet werden.
- Hoher Nutzen, hoher Aufwand: Bevor diese Einträge umgesetzt werden, müssen sie weiter zerkleinert oder neu gedacht werden. Stelle dazu die Frage: „Wie können wir den gleichen Wert mit geringerem Aufwand liefern?“
- Niedriger Nutzen, niedriger Aufwand: Diese Product-Backlog-Einträge können umgesetzt werden, wenn sich nichts Wichtigeres im Product-Backlog befindet. Sie sollten weiter unten im Backlog angeordnet werden.
- Niedriger Nutzen, hoher Aufwand: Diese Einträge sollten zunächst verworfen werden.
Vorteile der Gegenüberstellung von Nutzen und Aufwand:
- Nicht deine Meinung als Product-Owner, sondern die konsolidierte Meinung von Stakeholdern und Entwicklern bildet die Grundlage. Das sind belastbare Entscheidungsgrundlagen.
- Priorisierungsentscheidungen werden transparent und nachvollziehbar.
- Machtspiele und Wunschkonzerte verlieren ihre Wirkung.
Dieses Vorgehen vermittle ich genau so auch angehenden Product-Ownern in meinen „Professional Scrum Product Owner“-Trainings.
Denn ab diesem Punkt priorisierst du nicht mehr nach Bauchgefühl und machst dich dadurch angreifbar, sondern du schaffst belastbare Entscheidungsgrundlagen und setzt damit auch dem lautesten Stakeholder klare Grenzen.