Die ewige Diskussion: Story Points

Lesezeit ca. 4 Minuten

„Story Points? – Damit können wir nichts anfangen! Wir kennen uns jedoch mit Stunden und Personentagen aus“.

Dieser Ausruf begegnet mir immer wieder in neuen, aber auch in schon erfahreneren Dev-Teams. Das ist nicht schlimm, denn Story Points[1] sind für das Dev-Team uninteressant.

Für den Product Owner und den Scrum Master sind Story Points aber sehr wichtig: Der Product Owner kann damit eine Prognose zum Release-Termin abgeben, der Scrum Master kann die Story Point Zahl zum Trainieren des Scrum-Teams verwenden.
Das Dev-Team kann das Story Point Thema daher entspannt so sehen: Genauso, wie das Dev-Team das Produkt Inkrement liefert, stellt es auch die Abschätzung der Story zur Verfügung.

Der Produkt Owner kann durch die Story Point Abschätzung die Frage der Stakeholder nach dem Fertigstellungstermin beantworten: „Wir können pro Sprint ca. Themen mit zusammen 20 Story Points schaffen, wenn das Team und das Umfeld nicht verändert werden. Nach unserer derzeitigen Einschätzung würde das Feature für uns insgesamt ca. 100 Story Points bedeuten, also ca. 5 Sprints dauern.“ Der Produkt Owner sollte den wahrscheinlichen Release-Termin kommunizieren, ebenso den Best Case-Termin und den Worst-Case Termin.

Der Scrum Master kann die Story Points Schätzung verwenden, um dem Scrum-Team die Vorteile[2]  von kleineren Storys klar zu machen und den Zugewinn dieser Vorteile zahlenmäßig auszudrücken. Er kann die Entwicklung der Output-Leistung des Scrum-Teams ebenfalls zahlenmäßig ausdrücken und beurteilen. Dem Management kann er; wiederum mit Story Points, die Auswirkungen von Impediments auf die Output-Leistung des Teams deutlich machen und damit für ein besseres Verständnis von Ursache und Wirkung sorgen.

Warum werden dafür aber keine Stunden oder Personentage verwendet?
Story Points waren dazu gedacht, die Diskussion mit dem Management über Stunden und Personentage zu beenden[3]. Die stets gleiche Frage „Wann ist es fertig?“ sollte damit unterbunden werden, da sie nicht zu beantworten ist (siehe „Komplexer Kontext“ in meinem Blog).

Story Points haben eine Reihe von Vorteilen (die Reihenfolge der Aufzählung ist willkürlich)

  1. Story Points berücksichtigen nicht die geschätzte, zu investierende Zeit (Input-basiert), sondern versuchen, die Schwierigkeit und das Risiko der Aufgabe zu erfassen. Die Betrachtungsweise ist daher Output-basiert und stellt das Ergebnis in den Vordergrund, unabhängig von zeitlichen Aufwand.
  2. Die Abschätzung in Story Points geht schneller als in Stunden.
    Die verwendeten Story Point Zahlen (1, 2, 3, 5, 8, 13…) decken ansteigend Gruppen von einzelnen Story Point Werten ab. So steht z.B. eine „5“ für 4, 5, oder 6 Story Points, siehe Tabelle[4]. Damit werden mit steigendem Schwierigkeitsgrad Diskussionen über einzelne Story Point Werte unnötig. Es wird Zeit gespart, ohne dass sich die fehlende Genauigkeit negativ auswirkt[5].
  3. Aussagen wie „ungefähr 250 PT“ können das Team wird auf diesen Wert festnageln, obwohl es nur eine Schätzung ist. Jemand könnte auch auf die Idee kommen, das Team zu verdoppeln, um die Hälfte der Zeit zu sparen.
  4. (ggfs. weitere)

Story Points haben jedoch auch Nachteile (ebenfalls in willkürlicher Reihenfolge)

  1. Story Points sind ungewohnt.
    Es werden zwar Zahlen verwendet, aber die Einheit [Story Point] ist im geschäftlichen Umfeld ungewöhnlich. Wir kennen Zahlen im beruflichen Alltag meist nur in Verbindung mit den Einheiten [h], [PT], [€], [$], [FTE] usw.
  2. Story Points sind eine subjektive Einschätzung des Dev-Teams und daher nicht Team-übergreifend aussagekräftig.
  3. Story Points müssen gut mit Referenzstorys verankert sein, damit die Inflation der Story Points[6] gering ist. Die Referenzstorys sollten von Zeit zu Zeit (~ alle 10 Sprints) neu bewertet werden, um den Wissenszuwachs des Dev-Teams zu berücksichtigen.
  4. Story Points können ein Dev-Team dazu verleiten, zu viel Beachtung auf die Velocity (Story Points pro Sprint) zu legen
  5. Story Points können nicht gemessen werden, es gibt keine Objektivität.
  6. Story Points und die daraus entstehende Velocity können Führungskräfte dazu verleiten, diese zur Beurteilungen von Mitarbeitern heranzuziehen.
  7. (ggfs. weitere)

Man sieht, das Konzept der Story Points ist nicht perfekt. Beim Vergleich von drei Vorteilspunkte und sieben Nachteilspunkten könnte es naheliegend sein, auf die Verwendung von Story Points zu verzichten. Vielleicht findet jemand sogar irgendwann einen Weg, einige der Nachteile von Story Points durch eine neue Größe abzuschaffen. Bis dahin möchte ich jedoch an der Forderung in Richtung Dev-Team festhalten, eine Abschätzung in Story Points zu liefern.

 


[1] Story Points sind eine abstrakte Größe, die in Ganzen Zahlen einer (meist) abgewandelten Fibonacci-Reihe ausgedrückt werden, siehe Tabelle unten.

[2] Höhere Wahrscheinlichkeit der Fertigstellung, leichtere Handhabung, bessere Überschaubarkeit der notwendigen Aufgaben u.a.

[3] Ron Jeffries sieht sich mit der Erfindung der Story Points eng verbunden.

https://twitter.com/ronjeffries/status/307469737305186304?lang=de

[4] Story Point Zahl und abgedeckter Wertebereich

Story Point ZahlStory Point Werte
„1“1
„2“2
„3“3
„5“4, 5, 6
„8“7, 8, 9, 10
„13“11, 12, 13, 14, 15
„20“16, 18, 19, 20, 21, 22, 23, 24

[5] Man kann dies mit Toleranzklassen in der Fertigung vergleichen. Sofern ein Bauteil innerhalb der Toleranzgrenzen bleibt, ist die Funktion nicht beeinträchtigt. Eine übertriebene Genauigkeit treibt die Kosten nach oben, ohne dass ein Mehrwert erzielt wird. Dies ist Verschwendung.

[6] Man spricht von Inflation der Story Points, wenn für eine ähnliche Komplexität, Ungewissheit, Risiko usw. über einen längeren Zeitraum betrachtet immer höhere Story Point Zahlen vergeben werden.

cmm

Scrum Master, Agile Coach, QA-Experte, Autor

Schreibe einen Kommentar

[translate]
Christian M. Mann