Priorisieren des Product Backlog

Welche Methoden und Tricks helfen bei der Priorisierung des Backlog und zur Planung von Releases?

Agile Methoden maximieren Wertschöpfung in kurzen Zyklen. Eine zentrale Methode dazu ist die Zerlegung und Priorisierung in ‘vertikale’ funktionale Scheiben.

Die richtige Priorisierung ist der Schlüssel für die Entwicklung des richtigen Produkts.

Refinement, das Detaillieren und Anreichern des Backlog ist eine ständige Aufgabe für das Entwicklungsteam.

Die Diskussion über PBIs führt zu besser verstandenen Stories und einer realistischen Einschätzung. Je besser verstanden Stories sind, um so eher werden sie als ready markiert und sind damit bereit für die Implementierung.

Als Faustregel: wenn ungefähr 10% der zeitlichen Verfügbarkeit der Teammitglieder für das Refinement eingeplant sind, geschieht hinreichend viel um den Product Owner in der Priorisierung gut zu unterstützen. 

Stakeholder werden in Anforderungsworkshops oder Sprint Reviews mit in das Refinement einbezogen. Diese gemeinsame Arbeit schafft Dialoggeteilte Verantwortung und ein besseres und kollektives Verständnis der Zusammenhänge.

Ständiges und transparentes Priorisieren löst unaufwändig drei wiederkehrende Probleme:

  • Einen tragfähigen Konsens über die wichtigsten items herstellen, der länger anhält als die ersten Tage eines Sprint.
  • Mit einem tieferen und geteilten Verständnis kann schneller entschieden werden. Langwierige Planning Meetings werden verkürzt.
  • Die akut wertvollsten items werden im Dialog des Refinement identifiziert.

Nach welchen Kriterien priorisieren?

Wesentliche formale Faktoren für die relative Wichtigkeit und Priorität eines Features sind der Geschäftswert, das mit einem Feature identifizierte Risiko, die Opportunitätskosten (was könnte man mit demselben Aufwand noch anstellen?) und die Cost of Delay (CoD). Die CoD ist der in Geld formulierte Wert, ein Feature verzögert operativ zu haben.

  • Geschäftswert, Business Value:
    Wertvollere Funktionen werden zuerst entwickelt. So ist besser sicher zu stellen, dass bei unvorhergesehenen Verzögerungen auf jeden Fall die wichtigsten Teile fertig werden. So wird möglich, auch mit einem teilweise fertiggestellten Produkt erste Umsätze zu generieren.
  • Risiko
    Bei gleichem Geschäftswert haben riskantere Funktionen Vorrang. Gelingt deren Umsetzung nicht im ersten Anlauf, bleibt Zeit für die Entwicklung von Alternativen.
  • Kosten von Verzögerung / Cost of Delay:
    Mit einer inkrementellen Fertigstellung und Lieferung bringen neue Features einen direkt berechenbaren Mehrwert. Eine Verzögerung bedeutet im gleichen Sinn Kosten jenes nicht realisierten Mehrwertes. Es gibt Features mit unverhältnismäßig teuren oder prohibitiven Konsequenzen. Wenn etwa eine Änderung der Umsatzsteuer in einem eCommerce-System nicht umsetzbar ist, muss der Verkauf unterbrochen werden. Viele andere Beispiele gibt es aus regulierten Märkten, in denen gesetzliche Vorschriften realisiert sein müssen.
  • Konzeptionelle Integrität
    Wenn ein Release zu einem festen Zeitpunkt ausgeliefert werden muss, dann hat eine Mischung halb fertiger und nicht benutzbarer Features keinerlei Wert. Jedes Release muss damit aus einer gemäßen Menge fertiger und nutzbarer Features bestehen.
  • Technische Abhängigkeiten
    Leider sind Features nicht immer unabhängig von einander zu formulieren. Ein realistisches Beispiel sind technische Abhängigkeiten mit Umsystemen. In diesen Fällen muss eine dadurch bestimmte Reihenfolge der Fertigstellung eingehalten werden. Es kann sinnvoll sein, Basisfeatures als Platzhalter (stub) oder mit eingeschränkter Funktionalität zu entwickeln, um die Auswirkungen der Abhängigkeit/en zu begrenzen.

Methoden und Tricks zur Priorisierung

Zu den formalen und ökonomischen Parametern kommen informelle Faktoren, die ebenso ausschlaggebend sein können.

Wenn Features so klein sind, dass sie kaum gegeneinander gewichtet werden können, ist eine Priorisierung schwer. Oder wenn gleichwertige Features als Gesamtheit wahrgenommen werden. Ein Beispiel dafür: ist in einem Textverarbeitungsprogramm das ‘a’ oder das ‘e’ wichtiger, Tabellen oder eine ‘Rückgängig’-Funktion? Bei einem Auto das rechte oder linke Vorderrad?

Mike Cohn rät: zuerst über Epics priorisieren, dann Epics öffnen und nach Releases optimieren.

Mike Cohn

Mike Cohn rät: Zuerst über Epics priorisieren, dann Epics öffnen und nach Releases optimieren.


In vielen Fällen kann über eine Experteneinschätzung eine Priorisierung erreicht werden.

Ein qualitativer Weg ist der Einsatz des Kano-Modelles, mit dem der Einfluss von Features auf die Nutzerzufriedenheit eingeordnet werden kann. Eine kleine Testgruppe realer Nutzer wird dazu in einem bipolaren Interview befragt: “Wie finden Sie es, wenn diese Funktion vorhanden ist?” — “Wie käme es Ihnen vor, wenn dieses Feature nicht existierte?”. Die Auswertung der Antworten ergibt schnell ein wertvolles Bild der Sicht realer Nutzer.

Kategorien: Scrum
Schlagworte: Praktiken
Contributor: Krishan Mathis
Copyright © 2021 Radical Focus
Scroll to Top