✁
digitalien.org — Stefan Knecht
Priorisieren und Konfektionieren von Backlog und Releases
Welche Methoden und Tricks helfen bei der Priorisierung des Backlog und zur Planung von Releases?
Die richtige Priorisierung ist der Schlüssel für die Entwicklung des richtigen Produkts.
Ständiges und transparentes Priorisieren löst drei wiederkehrende Fragen:
- Konsens über die wichtigsten features herstellen, der länger hält als die ersten Tage eines Projektes
- Entscheidungen schnell treffen können … und langweilige, endlose Planning Meetings abkürzen
- die jetzt wertvollsten items finden … als vielleicht wichtigster Nutzen
Agile Methoden maximieren Wertschöpfung durch kurze Zyklen und ständige Lieferung funktionierender Software.
Eine zentrale Methode dazu ist die Zerlegung und Priorisierung in ‘vertikale’ funktionale Scheiben.
Vertikal, dann in die Breite
Vertikale Scheiben bedeutet an der Hamburger Metapher: nicht von unten nach oben den Hamburger perfekt belegen sondern ‘Durchstiche’ herstellen, dann besser werden und features detaillieren.
Video: nach Nutzen priorisieren
Das Video stammt von Krishan Mathis, ➚ Radical Focus.
Refinement und Priorisierung geschieht ständig
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 des Entwicklungsteams für refinement 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 Dialog, geteilte Verantwortung und ein besseres und kollektives Verständnis der Zusammenhänge.
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äfts-)Wert / 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, CoD
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.
Abnehmender Grenznutzen: das Wichtigste zuerst
Das Nützliche, wertstiftende Funktionen, funktionale must-have Features zuerst implementieren. Wenn im weiteren Verlauf Kapazität nach Beschäftigung schreit, dann erst die nice-to-haves umsetzen.
Denn: kommt es zu Verzögerungen, wird neu priorisiert, dreht die Welt sich überraschend einmal um sich selbst und ist schon wieder Weihnachten … dann ist die Zeit verstrichen, der Aufwand eingesetzt … und nicht das umgesetzt, was Nutzern hilft dabei, ein Problem/Transaktion/Aufgabe zu lösen.
Das Produkt mag dann vielleicht hübscher aussehen, bleibt aber von geringem Nutzen.
Also: vertikal, dann horizontal. Einmal durchstechen und die wesentlichen features grob bauen, danach feiner, schöner, angenehmer machen.
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 priorisieren, dann die Epics öffnen und nach Releases optimieren.
Die Gewichtung von features kann auch schnell durch eine Experteneinschätzung priorisiert werden.
Wer ist Experte für das Produkt? Genau: der PO — der steckt am Tiefsten drin im WAS und kennt die Kunden-/Nutzerbedürfnisse in- und auswendig. Weil er ständig Kontakt hat.
Das Kano-Modell kann nützlich sein
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?”
Mehr dazu: ➚ Das Kano-Modell: was wollen Nutzer wirklich?