Bang for the Buck Score – Wie Story Points und Value Points helfen das Backlog zu priorisieren.

Ein Freund von mir, der ebenfalls als Scrum-Master tätig ist, hat mich vor kurzem gefragt wie er mit Story Points umgehen soll. Er möchte einem Team das er coachet, dabei helfen von einer Stundenschätzung und Planung basierend auf Stunden, zu einer Story Point basierten Schätzung und Planung zu kommen. Aus einer kurze Frage wurd sehr schnell ein langes Gespräch über Story-Points, Value Points, Bang for the Buck Scores, Bugs, Schätzungen, Plannings und Time Boxing.

Story Points und Estimations

Menschen sind schlecht, wenn es um absolute Schätzungen geht. Wie viele Kilogramm hat eine Ananas? Wie viele Kilometer sind es zwischen Berlin und Wien? Wie lange dauert es ein Haus zu bauen? Wie viele Milliarden Dollar Gewinn macht Apple?

Wenn es aber um relative Schätzungen geht sind wir Menschen schon besser. Was ist schwerer dieser Apfel oder diese Ananas? Und wie viele Äpfel wiegen genauso viel wie diese Ananas? Zwei? Drei?

Der Unterschied in beiden Schätzungen ist die Komplexität. Von einer gesichtslosen Einheit wie Kilometer zu einer realen Entfernung zu schätzen ist schwieriger als einen Vergleich zwischen zwei realen greifbaren Dingen zu machen.

Genau diesen Effekt nutzen agile Schätzmethoden mit Story Points aus.
Wir nehmen ein beliebiges Backlogitem aus dem Backlog (Idealer weise ein kleineres) und geben dem Item einen Wert. Zum Beispiel könnte man 8 Story-Points für eine kleine bis mittlere Userstory vergeben.
In Sprintplannings oder Refinement-Meetings vergleicht man dann diese Referenzstory mit anderen Stories und vergibt dabei mehr oder weniger Punkte.

Wichtig dabei ist festzustellen dass Story-Points komplexitätsbezogene Aufwandsschätzungen mit einer für jedes Projekt individuellen Einheit sind. Daraus folgt dass in Entwicklungsorganisationen keine Einheitlichkeit zwischen den Story Points besteht und somit nicht (vom Management) zwischen den Projekten die Story Points (sowie die Velocity) verglichen werden können.

Story Points und Fibonacci

Wenn wir Storys vergleichen, warum schätzen wir dann die Story Points in Fibonacci-Zahlen? Diese Frage scheint sich kaum ein Developer oder Scrum-Master zu stellen. Die Antwort warum wir Fibonacci Zahlen verwenden liegt in ihrer Verteilung bzw. in ihrem Verhältnis zueinander.

  1. Die Reihe bildet immer zwischen zwei Zahlen eine Differnez von ca. +60%. Dieses Verhältnis wird auch als magische Zahl 1:1.618 oder Golden Ratio bezeichnet und ist überall in der Natur zu finden[1].
  2. Gleichzeitig wissen wir dass Menschen nur sehr schwer zu kleine Unterschiede wahrnehmen können. Laut dem Weber’s Law muss der prozentuelle Unterschied zwischen zwei Objekten eine gewisse Signifikanz haben, um von Menschen leicht wargenommen zu werden. Das Webersche Gesetz[2] besagt, dass der Unterschied, den wir zwischen Objekten feststellen können, durch einen Prozentsatz angegeben wird.
  3. Weiters wissen wir[3], das Menschen je nach Schätzmethode unterschiedliche Fehlerrate aufweisen. So wird bei Top-Down Schätzungen von Fehlerraten zwischen +/- 10% und +/-50% gesprochen. Während man bei intuitiven Schätzungen von Fehlerraten zwischen +/- 30% bis +/-100% ausgeht. Im Normalfall ist man also mit einem 60% Puffer gut abgesichert.

Was sind Story-Points?

Wie bereits erwähnt sind Story Points ein Maß für die Komplexität und den Umfang einer User Story/eines Tickets. Sie sagen nichts über den zeitlichen Aufwand für die Umsetzung des Tickets aus. Der Zeitliche kontext entsteht erst, wenn das Ticket einem Team oder einem Team-Mitglied zur Implementierung gegeben wird. Aufgrund ihrer fähigkeit Tickets miteinander in Beziehung zu stellen eignen sich Story Points sehr gut für eine Kosten-Nutzen Rechnung. Diese geschieht durch eine Kombination von Story Points mit Value-Points zu Bang for the Buck Scores.

Und was sind Value Points?

Value Points sind das Pendant zu Story Points. So wie Story Points ein Maß für den Umfang und die Komplexität eines Tickets sind, sind Value Points ein Maß für den Mehrwert welcher durch die erfolgreiche Implementierung beim User ankommt.

Der Bang for the Buck Score und die Priorisierung des Backlogs

Der Bang for the Buck Score ist ein Preis-Leistungsverhältnis. Er stellt die Story Points, (sozusagen den Preis) auf der einen Seite, den Leistungen (also den Value Points) gegenüber. Zur Berechnung des Bang for the Buck Score werden also die Value Points eines Tickets durch die Story Points dividiert.

  • 55 Value Points / 5 Story Points ergibt einen hohen Bang for the Buck Score von 10;
  • 8 Value Points / 8 Story Points ergibt lediglich einen Bang for the Buck Score von 1;

Zum Priorisieren des Backlogs kann der Bang for the Buck Score für alle Tickets berechnet werden und dieser dann für die Reihung der Tickets im Backlog herangezogen werden.

Story Points und Value Points im Bezug auf Bugs

Bugs werden nicht geplant, noch sind sie dem Team bewusst (sonst wären sie keine Bugs). Dennoch müssen Bugs irgendwie in den Sprint gelangen (geplant werden). Hierzu gibt es verschiedene Strategien. Zum Beispiel kann ein Team eine Zero-Bug-Policy verfolgen und jeden noch so kleinen Bug der reported wird sofort mit der Priorität 1 beheben. Oder aber es wird pro Sprint ein gewisser Puffer für Bugs freigelassen. Der Sprint wird also nicht voll verplant und Bugs durchlaufen in einer seperaten Swimlane den Sprint. Meistens werden Bugs aber im Zuge des Sprint Plannings in den Sprint gezogen. Dazu müssen sie geschätzt und priorisiert werden. Da Bugs aber schwer planbar und schätzbar sind, ist dies eine schwierige Aufgabe. Der Bang for the Buck Score kann hierbei helfen.
In der Praxis werden Bugs nach ihrer planbarkeit unterschiedlich behandelt. Ist bei einem Bug verständlich wo das Problem liegt und wie es behoben werden kann, kann der Aufwand zur Behebung des Bugs geschätzt werden. In der Regel trifft dies aber nicht auf viele Bugs zu, wesswegen eine andere Strategie gewählt wird.
Der Bug wird mit einer Time-Box versehen. Da Sprints aber oft mit Velocity und Story Points geplant werden, muss neben der Time-Box ein gewisser Story Point Wert zugewiesen werden. So können zum Beispiel alle Bugs 5 Stroy Points bekommen. Die Höhe dieser Story Points pro Bug Ticket richtet sich nach der Granularität des Backlogs und ist von Team zu Team unterschiedlich.
Da Bugs keinen zusätzlichen Mehrwert zum Produkt darstellen sondern einen fehlenden Mehrwert aufzeigen können sie negative Value Points bekommen. Das heißt sehr kritische Bugs erhalten einen hohen negativen Value Points Wert.
Wird der Bug gelöst, so bekommt das Produkt diese fehlenden Value Points zurück. Der Bang for the Buck Score ist also dennoch positiv und kann gleich berechnet werden wie bei Feature-Tickets. Das negative Vorzeichen entfällt dabei.

Zusammenfassung

Zusammengefasst lässt sich sagen dass Story Points und Value Points mit dem Bang for the Buck Score dem Team und dem PO dabei helfen das Backlog zu priorisieren und gleichzeitig auch ein Tracking vom generierten Mehrwert des Sprints ermöglichen. Auch Bugs lassen sich mit negativen Value Points und den zurückgewonnenen positven Mehrwert bei der Behebung gut in diese Methode einordnen und sind kein Widerspruch.

[1] Golden Ratio: https://medium.com/@akarsh.sharma/the-magic-of-fibonacci-numbers-f428b5728034

[2] Webers Law: https://www.mountaingoatsoftware.com/blog/why-the-fibonacci-sequence-works-well-for-estimating

[3] Schätzgenauigkeit: https://digitalisierungscoach.com/2018/06/28/softwareprojekte-richtig-schaetzen/

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: