Freitag, 29. März 2024
Seite wählen

Anregungen aus und für die Praxis — Product Backlog "Priorisierungen"

Versäumnisse in der aktiven Priorisierung des Product Backlogs lassen häufig erhebliches Potenzial ungenutzt liegen. Einige Projekte scheitern sogar. Erfahrungen und Beispiele aus einigen Scrum-Projekten …

Üblicherweise werden die Einträge eines Product Backlogs [PBL] in irgendeiner Weise sortiert bzw. priorisiert – hoffentlich vom Product Owner [PO]. Zu häufig erlebe ich in diesem Zusammenhang, dass einige PO dieses Thema gern vernachlässigen, es als lästig empfinden … und damit das erhebliche Potenzial und die (Release-) Planungsmöglichkeiten ungenutzt lassen.

Nähern wir uns z.B. über den → Scrum Guide (Stand Oktober 2011):

Das Product Backlog … ist eine geordnete Liste mit allem, was in dem Produkt benötigt werden könnte …
… wird häufig nach Wert, Risiko, Priorität und Notwendigkeit angeordnet …

PBL-Einträge an der Spitze bestimmen die unmittelbaren Entwicklungsaktivitäten …

1. PO → „Smells“

Wie sieht es aus, wenn der PO das PBL nicht pro-aktiv – also auch im Sinne einer Release-Planung – nutzt ?

Hier einige [teils subjektive] Erlebnisse – auch zur Sensibilisierung:

  • von einem PO mit noch wenig Scrum-Kenntnissen [oder von einem PO der → „Scrum, but“-Fraktion], der Chancen und Potenziale einer PBL-Sortierung noch nicht verstanden hat, hört man gern als „Argument“ sich damit nicht aktiv beschäftigen zu wollen/müssen:

    … es muss eh alles umgesetzt werden …

    … fangt einfach mit den ersten Stories an …
    [aus dem Bauch, hoffentlich aus seiner Erfahrung heraus, hat er die Stories schon mal irgendwie sortiert]

  • auf den Vorschlag als mögliches Kriterium den → ROI oder den „Business Value“ [BV] einer Story für eine Sortierung zu nutzen, kann man auch erleben, dass der PO entweder antwortet „zu kompliziert“ [ROI] oder einfach schon mal an jede Story einen „13er BV“ klebt („… den Rest machen wir später …“ [also nie]) oder an den Scrum Master gerichtet lamentiert „… das kannst Du ja schon mal mit den Entwicklern besprechen …“
  • angesprochen auf die Möglichkeit einer „Risko-Bewertung“, z.B. von Security-relevanten Stories, habe ich auch schon ein „… die [Stories] machen wir ganz zum Schluss …“ gehört – unter Umständen sehr gefährlich, hier bleibt ein aktives und professionelles Risiko-Management ungenutzt
  • gern werden in einem solchen Projekt- bzw. Planungs-Umfeld, oder von einem PO mit diesem speziellen Mindset, Stories mit einem „Due Date“ ganz spontan in den nächsten Sprint „rein gedrückt“
  • häufig wird der Fokusierungs-Vorteil durch eine Themen-Clusterung nicht angewendet – der Vorteil, solche Gruppierungen als → Sprint Goal zu nutzen, bleibt wirkungslos

Nachfolgend einige Anregungen, wie man sich aktiv mit den Sortierungs- und damit Priorisierungs-Möglichkeiten eines PBL beschäftigen und zum Wohlergehen und Erfolg des Projektes nutzen kann.

2. Praxis-Beispiel

Bei dem Vergleich mehrere Scrum-Projekte komme ich immer wieder zu ähnlichen Ergebnissen (nachstehend stellvertretend die Zahlen eines „Banking“-Projektes auf eine 100 %-Skala „normalisiert“).

Ausgangspunkt sind etwas über 100 Stories und das „aus dem Bauch heraus“ sortierte PBL eines erfahrenen Produkt-Managers, der die PO-Rolle inne hatte. Vorbereitende Abstimmungen mit den beteiligten Stakeholdern und Fachbereichlern hatten teilweise stattgefunden. Das PBL wurde in insgesamt drei Workshops initial mit dem Scrum-Team erarbeitet und diskutiert. Einige Stories wurden aufgrund von Team-Vorschlägen nach vorn bzw. hinten geschoben.

Story Point-Schätzung

Mittels → Planning Poker wurden Story Points (Complexity) geschätzt. Für jede Story wurde zusätzlich ein Business [BV] und Risk Value [RV] ermittelt.

Im Diagramm zu sehen ist der theoretische Planungs-Rückblick auf einen → Burndown-Graphen über die Komplexität, der sich ergeben hätte, wenn die diskutierte Reihenfolge der Stories vom Ende des zweiten PBL-Workshops zur Projektarbeit herangezogen worden wäre.

Vom Team wurden tendenziell Stories mit kleineren Story Point-Werten, also geringerer Komplexität an den Anfang geschoben. Ein solches Ergebnis erlebt man bei in Scrum oder im Planning noch weniger erfahrenen Teams häufiger – man macht halt die einfacheren Dinge lieber zu erst.

Diese Sortierung ähnelt der rein mathematischen Sortierung „von kleiner nach großer Komplexität“:

Der Graph im linken Bild verläuft „oberhalb“ der Vergleichslinie, die sich beim „Abbrennen“ gleich „großer“ Stories über die Projekt-Laufzeit ergeben würde.

Würde man die Sortierung streng von „größtem zu kleinstem Story Point-Wert“ wählen, also zunächst die komplexeren Stories und zum Projektende die einfacheren bearbeiten, erhält man den Verlauf des rechten Bildes. Bei einer solcher Sortierung verläuft die Kurve dann unterhalb der Vergleichslinie.

In dem zitierten Projekt würden mit diesem Sortierungs-Ansatz durch die ersten 20 Stories bereits über 50 % der Komplexität „abgebrannt“. Da eine der Schätz-Prinzipien die Unabhängigkeit der Stories untereinander fordert, wäre bereits hier das → Pareto-Prinzip ein Hinweis bzw. ein erstes Planungssignal an den PO. Gern wird dieser Ansatz auch – unter der Annahme, dass bei höherer Story-Komplexität vielfach auch das Story-Risiko steigt – für ein Risiko-Management genutzt. Wie sich weiter unten zeigt, ist diese Annahme nicht belastbar.

Optimierungen

Im weiteren Verlauf eine kleine Diskussion über weitere Priorisierungs-Ansätze:

Business Values als Kriterium

Im linken Diagramm sieht man die ursprüngliche, noch nicht verbesserte Sortierung, nun mit zusätzlich eingeblendetem Burndown der „Business Values“ [die Feature-Wertung wurde nach einem → MoSCoW Clustering anschließend mittels → Pseudo Fibonacci-Werten verfeinert]. Auch hier sieht man die in der Praxis häufiger anzutreffenden kleineren BV-Werte zum Projektstart. Der Planungs-Vorteil über eine BV-Optimierung bliebe ungenutzt.

Im rechten Bild wurde die Sortierung nun nach BV optimiert (von „höchstem zum niedrigsten“ BV). Der Komplexitäts-Burndown-Graph bewegt sich fast unbeeinflusst in der Nähe der Vergleichslinie.

Sehr gut zu erkennen ist auch hier, dass mit dieser Optimierungsart nach nur 20 Stories bereits über 50 % des Projekt-Wertes hätte geschaffen werden können. Weitere 30 Stories – also nach nur der Hälfte aller Stories – würden genügen, um insgesamt 80 % Projekt-Wert zu schaffen.

Auch mit dieser Betrachtung hat der PO bereits wesentlich verbesserte Planungshinweise.

Priorisierung mittels Risk Value

Zunächst wieder die ursprüngliche, „Bauch optimierte“ Sortierung, diesmal samt eingeblendetem Risk Value-Burndown [Werte ebenfalls nach → Pseudo Fibonacci – Bild links].

„Gefahren-Indikator“ wäre hier die abgebrannten RV von nur ca. 30 % nach immerhin zwei Dritteln der abgearbeiteten Stories. Auf die restlichen Stories entfielen immer noch 70 % der Risiken und ca. 40 % der BV-Summen !

Im Vergleich die Priorisierung über den RV (von „höchstem zum niedrigsten“ Risiko, rechtes Bild): nach 20 Stories wären über 50 % der Projekt-Riskiken, nach 40 Stories bereits 80 % der Risiken „erledigt“. Allerdings blieben bei dieser Priorisierungs-Art noch ca. 60 % bzw. 50 % der BV offen.

Auch hier wieder ein sehr guter Anhaltspunkt für ein Release Planning.

[Hin und wieder hört man – wie oben im Nachsatz zu „Story Point-Schätzung“ erwähnt – vom PO den spontanen Hinweis, dass Complexity und Risk Value insgesamt korrelieren würden und es deshalb genügen würde, vereinfachend [und Arbeit sparend] die Complexity zu betrachten. Bei einzelnen Stories mag es hier einen Zusammenhang geben. Im beiden Diagrammen, insbesondere im rechten Bild nach der RV-Optimierung, sieht man jedoch, dass die beiden Burndown-Graphen deutlich voneinander abweichen. Dies ist keine Besonderheit genau der Daten des betrachteten Projektes. Diesen Zusammenhang erlebe ich bei vielen Projekten.]

Risk UND Business Value-Optimierung

Die bisherigen Überlegungen dienten im konkreten und in weiteren Projekten als Basis für einen Sortierungs-Ansatz, bei dem die Optimierung über eine Signifikanz-Kennzahl durchgeführt wurde. Diese Kennzahl wird im Wesentlichen durch RV und BV ermittelt. Dabei werden die RV deutlich höher gewichtet.

Im Diagramm [[links und ff]] werden die Werte nun in üblicher Art gegenüber der Projektlaufzeit bzw. den Sprints dargestellt.

Nach einer Zwei-Drittel-Projektlaufzeit-Betrachtung hatten sich durch die Stories-Umsetzungen 93 % der RV- und ca. 90 % der BV-Summen erledigt.

Der PO und die Geschäftleitung hatten nach Vorlage dieser Ergebnisse sogar kurzfristig vor das Projekt mit diesem Stand abzuschließen.

Velocity-Betrachtung

Manchmal wird vom Management oder PO eher als Ziel eine Velocity-Maximierung offen oder latent gefordert, als den Blick auf die geschaffenen Werte [BV] oder erledigten Risiken [RV] zu lenken. Es wird fast sklavisch am Velocity-Puls jede kleinste Veränderung verfolgt. Zeigt diese nur marginal nach unten, hört man schnell ein „… habt ihr Probleme … werden wir zeitig fertig … ?“. Erfahrungen zeigen, dass eher ein Helikopter-Blick mit entsprechend mehr Weitsicht auf die Velocity als Indikator gesamtheitlich nutzt [manchmal „hilft“ bei sehr „zahlen-orientierten“ Managern mittels der ein oder anderen mathematischen Funktion auch einen „geglätteten“ Velocity-Graphen zu pflegen].

Nach einer Vorbereitungsphase von vier Wochen, in der u.a. die Projekt-Vision kommuniziert wurde und die Vorbereitungs-Workshops mit ersten Abstimmungen der nicht-scrummenden Abteilungen erfolgten, lief das Scrum-Projekt über insgesamt 42 Wochen mit anfänglich Zwei-Wochen-Sprints.

Nach dem fünften Sprint hatte die Velocity ca. 70 % der in dem Projekt maximal erzielbaren Velocity erreicht. Interessanterweise waren bereits über 60 % RV und fast 40 % BV „abgearbeitet“.

Aufgrund von sich überlagernden Ursachen sank die Velocity im Folge-Sprint auf ca. 40 % ab [Ergbnisse einer Retrospektive waren Versäumnisse in der Themen-Cluster-Bildung und konzern-interne Konstellationen, die die Umstellung auf Ein-Wochen-Sprints notwendig machten].

Im weiteren Verlauf stieg diese bis zum „Zwei-Drittel-Projektlaufzeit“-Sprint in Richtung 90 % an. Zu diesem Zeitpunkt wurde kurzfristig an die Beendigung des Projektes gedacht, da – wie oben geschildert – bereits Stories mit über 90 % RV- und BV-Summen abgearbeitet waren. Die Velocity fiel durch diese Irritation kurzfristig ab [Retro-Ergebnis]. Kurz vor Projektende zeigte sich ihr Maximum.

3. Lessons Learned

Immer wieder erlebe ich einen überraschten PO, der über Scrum gehört hatte, dass die Scrum-„Methodik“ angeblich ungeeignet für Risiko-Betrachtungen sei [und dabei irgendwie froh war die Verantwortung nicht übernehmen zu können/müssen].

Die für den Artikel herangezogenen Daten des zitierten Projektes sind natürlich nicht repräsentativ. Sie zeigen jedoch auffallend große Ähnlichkeiten mit parallel betrachteten Projekten – übereinander gelegte Diagramm-Folien von Vergleichs-Projekten sind erstaunlich kongruent.

Dies kann bedeuten, dass sich bei aktiver Optimierung des PBL’s intensive Steuerungsmöglichkeiten und Verbesserungspotenziale erzielen lassen.

Auch ein „erfahrenes“ Bauchgefühl nutzt dieses Potenzial einer aktiven Optimierung unter Berücksichtigung von beispielsweise Business oder Risk Values kaum. Insbesondere die immer wieder in [Scrum-?] Projekten erlebte vernachlässigte Risiko-Betrachtung ist auch ein gewichtiger Grund für das Scheitern von Projekten.

Auf jeden Fall bietet sich als → Hebelwirkung mindestens z.B. eine Optimierung nach Business Values an. Vielleicht sind die „restlichen 10 % Stories“ wirklich nur noch „nice-to-have“ und das Budget könnte für „Wert-volleres“ genutzt werden …

about "Boeffi" ...CU
@ Boeffi  .net     aktualisiert am 24.05.2018