Die Backlog-Priorisierung ist eine der wichtigsten Hauptaufgaben eines jeden Product Owners. In der Praxis erfolgt sie jedoch oft “aus dem Bauch heraus” oder nach der Maxime: “Wer am lautesten schreit, wird als Erster bedient.” Für die kontinuierliche Wertsteigerung Deines Produktes ist das jedoch oft nachteilig.
Backlog-Priorisierung anhand des Produktziels oder Objectives & Key Results
Die erste sinnvolle Möglichkeit, Dein Backlog zu priorisieren, liefert Dir der Scrum Guide bereits mit: Das Produktziel in Scrum hilft Dir dabei, die Wichtigkeit von Product Backlog Items zu bewerten und die Reihenfolge von Features dadurch zu bestimmen, ob bzw. wie stark sie auf die Erreichung dieses Ziels einzahlen.
Damit stellen auch OKR eine gute Möglichkeit dar, Dein Backlog so zu priorisieren.
Dazu ordnest Du jedes Feature oder User Story einem Key Result zu. Features, die nicht auf (aktuelle) Key Results einzahlen, stehen weiter unten in Deinem Product Backlog.
Backlog-Priorisierung nach dem MoSCoW-Prinzip
Das MoSCoW-Prinzip geht auf Dai Clegg zurück, der diese Methode während seiner Zeit bei Oracle entwickelte. Du kannst sie besonders dann gut anwenden, wenn Deadlines eine wichtige Rolle in Deinem Projekt oder Deiner Produktentwicklung spielen. (Beispielsweise, wenn feste Release-Zyklen existieren.)
Die Priorisierung Deines Backlogs richtet sich bei der MoSCoW-Methode nach vier verschiedenen Feature-Kategorien:
Must Haves sind absolut notwendige Features, die bis zu einem anvisierten Zeitpunkt vorhanden sein müssen. Falls sie fehlen, macht das Dein Produkt absolut unbrauchbar.
Should Haves stehen für ebenfalls sehr wichtige Features. Allerdings führt ihr Fehlen nicht dazu, dass Dein Produkt unbrauchbar wird, sondern für Deine Nutzer “nur” (schwerwiegende) Einschränkungen erzeugt.
Could Haves sind Features und Funktionen, die grundsätzlich wünschenswert sind, auf die Deine Kunden jedoch auch (vorerst) verzichten könnten, falls es zeitlich eng wird.
Unter Won’t Haves finden sich Produktmerkmale, die derart unwichtig sind, dass Nutzer auch komplett auf sie verzichten könnten, und die deshalb bis zur anstehenden Deadline nicht entwickelt werden.
User Story Mapping zur Backlog-Priorisierung
User Story Mapping ist eine Technik, die von Jeff Patton entwickelt wurde. Der größte Vorteil dieser Priorisierungsmethode ist der, dass sie Dein Product Backlog um eine zweite Dimension erweitert, die entlang der Customer Journey verläuft.
Mit Hilfe von User Story Mapping bist Du beispielsweise in der Lage, ein Walking Skeleton zu definieren oder Basis-Features für ein einsatzfähiges Minimum Viable Product zu entdecken.
Außerdem behältst Du durch User Story Mapping stets die Jobs to Be Done Deiner Nutzer im Blick, die Dein Produkt für sie erledigen soll.
Darüber hinaus ist User Story Mapping auch mit dem oben erwähnten MoSCoW-Prinzip kompatibel, sodass Du diese Methode als sinnvolle Ergänzung zur Priorisierung Deines Backlogs nutzen kannst.
Backlog-Priorisierung mit der WSJF-Methode
Die WSJF-Methode (Weighted Shortest Job First) hilft Dir als Product Owner dabei, Projekte (oder auch die Entwicklung von Produkt-Features) in eine sinnvolle Reihenfolge zu bringen, um sogenannte Verzögerungskosten (Cost of Delay) zu minimieren.
Features, die mit möglichst wenig Aufwand viel Nutzen stiften, werden bei dieser Methode höher im Backlog priorisiert als Features, die wenig Nutzen stiften und sehr aufwändig sind.
Zwar ist die WSJF-Methode ein offizieller Bestandteil des SAFe-Frameworks, allerdings unterscheidet sie sich nur wenig von der CD3-Methode aus dem Lean Management bzw. Kanban.
| Projekt | Wert | Zeit | WSJF |
|---|---|---|---|
| Projekt E | 5.000 € | 2 Sprints | 2.500 |
| Projekt C | 20.000 € | 9 Sprints | 2.222 |
| Projekt D | 15.000 € | 7 Sprints | 2.143 |
| Projekt B | 10.000 € | 5 Sprints | 2.000 |
| Projekt A | 10.000 € | 8 Sprints | 1.1250 |
Priorisieren mit dem Kano-Modell
Das Kano-Modell unterstützt Dich dabei, Features hinsichtlich ihres Beitrags zur Kundenzufriedenheit zu bewerten. Es unterscheidet zwischen fünf verschiedenen Feature-Kategorien:
Mit Hilfe des Kano-Modells kannst Du Dein Product Backlog anhand dieser fünf Kategorien priorisieren und Dich beispielsweise darauf fokussieren, zunächst wichtige Basismerkmale zu entwickeln, bevor es darangeht, eine Vielzahl von Begeisterungsmerkmalen umzusetzen.
Denn wer kauft schon ein Produkt, dass zwar echte Wow-Features hat, aber die grundlegendsten Dinge nicht kann?
Backlog-Priorisierung anhand des Opportunity Scores
Die letzte Möglichkeit zur Priorisierung Deines Backlogs, die ich Dir vorstellen möchte, ist der sogenannte Opportunity Score. Diese Methode ist Teil des Outcome Driven Innovation Frameworks, das von Anthony Ulwick entwickelt wurde. Mit dem Opportunity Score berechnest Du einen Zahlenwert, der zum einen darauf basiert, wie wichtig das Ergebnis einer konkreten Aufgabe für Deine Nutzer ist, zum anderen jedoch auch beinhaltet, wie zufrieden sie derzeit sind, dieses Ergebnis auch zu erreichen.
Möglich wird dies durch die beiden folgenden Fragen:
Beide Fragen werden jeweils von Deinen Nutzern bewertet (beispielsweise auf einer Skala von 0 bis 10) und miteinander verrechnet, sodass sich der Opportunity Score ergibt. Ermittelst Du diesen für jedes Deiner Features, kannst Du Dein Backlog anhand dieses Zahlenwertes priorisieren. (Oder bestimmte Features ganz ausschließen, falls sie unter einem vorher festgelegten Wert liegen.
Fazit
Wie Du siehst, gibt es jede Menge Möglichkeiten, Dein Product Backlog zu priorisieren. Wie steht’s bei Dir? Nutzt Du schon eine (oder mehrere) der hier genannten Methoden? Wie sind Deine Erfahrungen damit? Oder nutzt Du eine Methode, die hier nicht aufgeführt ist und dringend ergänzt werden sollte?
Dann schreib mir doch einen Kommentar hier unten auf der Seite! Ich bin gespannt auf Dein Feedback, Anregungen und Kritik.
