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.

Das laufende Verfeinern, das ‘refinement’ des Backlog ist eine Aufgabe für das Entwicklungsteam und führt zu besser detaillierten und besser verstandenen items, so dass diese ready und damit reif für die Implementierung werden.

Als Faustregel: wenn ungefähr 10% der zeitlichen Verfügbarkeit der Teammitglieder dafür eingeplant sind, geschieht hinreichend viel um den Product Owner in der Priorisierung gut zu unterstützen. Stakeholder werden etwa über Anforderungsworkshops oder in Sprint Reviews mit einbezogen. Diese gemeinsame Arbeit schafft Dialoggeteilte Verantwortung und ein besseres und kollektives Verständnis der items und ihrer Zusammenhänge.

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

  • Konsens über die wichtigsten items herstellen … der länger hält als die ersten Tage eines Sprint
  • Entscheidungen schnell treffen können … und langweilige, endlose Planning Meetings abkürzen
  • die jetzt wertvollsten items finden … als vielleicht wichtigster Nutzen

Welche Parameter bestimmen das Rangieren und Priorisieren?

Wesentliche formale Faktoren für die relative Wichtigkeit und Priorität eines features sind Geschäftswert, Risiko, Opportunitätskosten und die cost of delay (CoD):

  • 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. Unter Umständen ist es so auch möglich, mit einem teilweise fertiggestellten Produkt erste Umsätze zu generieren.
  • Risiko: Bei gleichem Wert 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 des Mehrwertes, der nicht realisiert werden konnte. 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 für den Betrieb realisiert sein müssen.
  • Konzeptionelle Integrität: Wenn ein Release zu einem festen Zeitpunkt ausgeliefert werden muss, dann hat ein Konglomerat 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 zu formulieren, da technische Abhängigkeiten auch mit Umsystemen bestehen. 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 kommen informelle Faktoren, die ebenso ausschlaggebend sein können.

Etwa, wenn Features so klein sind, dass sie kaum gegeneinander gewichtet werden können. Oder wenn gleichwertige Features als Gesamtheit wahrgenommen werden: 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 zu priorisieren, sie dann zu öffnen und nach Releases zu optimieren.

Mike Cohn
Mike Cohn

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 befragt: “Wie finden Sie es, wenn diese Funktion vorhanden ist?” — oder die dysfunktionale Frage “Wie käme es Ihnen vor, wenn dieses Feature nicht existierte?”

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