Story Points sind sinnlos – messt die Queue

• Story Points sind völlig unzuverlässig, sorgen für Verwirrung, und man muss Beteiligten ständig in Erinnerung rufen, was sie bedeuten
  • Niedrige Punktwerte sind präziser, aber hohe Punktwerte setzen eine hohe Variabilität voraus und repräsentieren eine Spanne, sodass sie sich nicht exakt aufsummieren lassen
  • Story Points stehen nicht für Zeit, aber in Kombination mit Velocity-Metriken bedeuten sie faktisch doch Zeit und untergraben von Anfang an das Addieren von Zahlen und Spannweiten
• Software-Schätzungen sind schwierig, und der Output des Prozesses ist im Vergleich zum Input im Allgemeinen nicht besonders nützlich
• Kleine Teams mit wenigen Unterbrechungen wirken so, als könnten sie präzise schätzen, wodurch meist der Eindruck entsteht, dass das eigene Vorgehen gut funktioniert
• Wenn die Capacity vollständig ausgelastet ist, steigt die Variabilität aller Arbeiten stark an und beeinflusst dadurch alle Schätzungen und Zeitpläne massiv
• Eine gemessene Queue löst kurz- und langfristige Schätzprobleme, verarbeitet Scope-Änderungen auf natürliche Weise und bietet großen Teams eine deutlich wertvollere Praxis, indem sie Unsicherheit beseitigt
• Eine gemessene Queue liefert einen Frühindikator, der Probleme 20-mal schneller vorhersagt als Velocity- oder Cycle-Time-bezogene Metriken

Was sind Story Points?

• Laut Atlassian sind Story Points eine Einheit, mit der sich der gesamte Aufwand schätzen lässt, der erforderlich ist, um einen Product-Backlog-Eintrag oder eine andere Arbeit vollständig umzusetzen
• Punkte stehen für Komplexität, Arbeitsaufwand, Risiko oder Unsicherheit sowie die Menge an Arbeit
• Die Messung von Komplexität ist ein relatives Konzept; verschiedene Teams können dieselbe Arbeit unterschiedlich bewerten
• Aufgrund des relativen Charakters von Punkten ist ein Vergleich zwischen Teams bedeutungslos, was auf Management-Ebene häufig zu Problemen führt

Eingebaute Variabilität

• Story Points basieren auf der Fibonacci-Folge; je höher der Wert, desto größer die ausgedrückte Variabilität
• Punktwerte mit hoher Variabilität zu addieren ist sinnlos, und das Aufsummieren von Punkten in Velocity-Metriken ist falsch
• Nach Goodharts Gesetz gilt: Sobald ein Messwert zum Ziel wird, taugt er nicht mehr als guter Messwert

Bekannte Probleme

• Die Probleme von Story Points sind gut bekannt, sie werden aber weiterhin verwendet, weil alternative Schätztechniken unter ähnlichen Problemen leiden
• Ron Jeffries, der Erfinder der Story Points, distanziert sich davon und kritisiert deren Missbrauch
• In Scrum wurde "Commitment" zu "Forecast" geändert, wird aber weiterhin falsch verwendet
• Es entsteht die paradoxe Situation, dass man sogar gerügt wird, wenn man mehr schafft als geschätzt

Priorisierung nach ROI

• Unternehmen priorisieren Arbeit, um Ressourcen wie Zeit, Geld, Werkzeuge und Menschen optimal einzusetzen
• Entwicklungsschätzungen sind nötig, um die Investitionskosten zu berechnen, aber das Schätzen selbst ist schwierig und teuer
• Software Estimation: Demystifying the Black Art ist ein hervorragendes Buch über die Schwierigkeiten des Schätzens

Der Output des Prozesses

• Der Prozess der Story-Point-Schätzung kostet viel Zeit, liefert aber keinen wertvollen Output
• Regelmäßige Grooming-Sessions sind zeitaufwendig und werden zwischen Teams uneinheitlich und unterschiedlich angewendet
• Wertvoller als Story Points ist es, eine sinnvolle Liste von Aufgaben zu erstellen

Vorgeschlagene Alternative

• Eine Schätzung mit T-Shirt-Größen kann eine bessere Alternative sein, hat aber ebenfalls Probleme
• Auch Schätzungen in Zeit haben ähnliche Probleme, weil die tatsächliche Arbeitszeit des Teams und die auf Business-Seite erwartete Zeit voneinander abweichen
• In kleinen Teams können Zeitschätzungen gut funktionieren, aber je größer das Team wird, desto geringer wird ihre Genauigkeit
• Donald Reinertsens Buch "The Principles of Product Development Flow" stellt eine Alternative vor
  • Entscheidend ist, den Arbeitsfluss durch Fokus auf Queue-Management zu optimieren
  • Man sollte Capacity planen und Pufferkapazität sichern, um Variabilität auffangen zu können

Die Lösung

• Ausgangspunkt ist, dass das Team die Arbeit gemeinsam analysiert, in kleine Tasks zerlegt und Unsicherheit entfernt
• Die Task-Liste wird zur Queue, und die Gesamtzahl der Tasks steht für die Größe der Arbeit (Job Size)
• Statt Story Points wird zur Schätzung die durchschnittliche Task-Abschlussrate (Average Task Rate) verwendet
• Die Arbeit wird auf Basis der durchschnittlichen Arbeitsgeschwindigkeit verfolgt, und die Task-Abschlussrate wird berechnet
• Wenn Tasks mit neuen Informationen oder Feedback aktualisiert werden, passt sich die Schätzung ganz natürlich an
• Entwickler müssen nicht unter psychologischem Druck durch Schätzungen stehen

Queue als Frühindikator

• Durchschnittliche Task-Abschlussrate, Cycle Time, Velocity usw. sind nachlaufende Indikatoren, die Queue dagegen ist ein Frühindikator
• Wenn die Größe der Queue wächst, lassen sich Probleme frühzeitig erkennen und Gegenmaßnahmen einleiten

Zusammenfassung

• Story Points stiften Verwirrung, sind unzuverlässig und so angelegt, dass sie scheitern
• Stattdessen ist es sinnvoller und wertvoller, Zeit darauf zu verwenden, dass das Team gemeinsam das Problem versteht, Unsicherheit beseitigt, die Arbeit in Tasks zerlegt und die Queue verwaltet

Meinung von GN+

• Der im Artikel vorgeschlagene Ansatz des Queue-Managements wirkt als realistische Alternative, um die Schwierigkeiten von Schätzungen in der agilen Entwicklung zu überwinden
• Allerdings kann das Zerlegen in kleine Tasks für Entwickler zusätzlichen Aufwand bedeuten, und in frühen Projektphasen kann es mehr Zeit kosten
• Außerdem setzt der Task-Analyseprozess die aktive Beteiligung der Entwickler und offene, ehrliche Rückmeldungen voraus
• Gleichzeitig ist ein positiver Effekt zu erwarten, weil das Entwicklungsteam die Business-Anforderungen tiefgehender versteht und gemeinsam darüber nachdenkt

[heal9179]

Ist das nicht die Kanban-Methodik..?

[GN⁺]

Hacker-News-Kommentare

• Meiner persönlichen Erfahrung nach war die Zahl der Story Points nicht wichtig, aber der Prozess, in dem das Team die Komplexität der Arbeit bewertet, war sehr nützlich

  • Story Points zur Schätzung der Arbeitszeit zu verwenden, war keine verlässliche Kennzahl
  • Aus verschiedenen Gründen wie Veränderungen im Team und im Fachbereich sowie der Schwankungsbreite von Aufgaben außerhalb der Entwicklung versuche ich, Story Points zu vermeiden
  • In Teams, die Story Points verwendeten, wurden sie als Werkzeug genutzt, um ein gemeinsames Verständnis der Arbeit herzustellen

• Dass im Scrum Guide „Commitment“ zu „Forecast“ geändert wurde, war nicht 2011

  • Beim Prüfen der Guides von 2010 und 2011 zeigte sich, dass das Wort „Commitment“ in Versionen vor 2011 nicht vorkam
  • „Forecast“ ersetzte im Guide von 2020 „Estimate“

• Arbeitspakete in atomare Einheiten zu zerlegen und die Queue-Länge zu messen, ist eine Frage auf einer anderen Ebene

  • Beim Verfeinern der Arbeitspakete mit dem Team kann man Story Points verwenden
  • Es war ineffizient, alle Aufgaben in 1-Story-Point-Einheiten zu zerlegen
  • Den Zusammenhang zwischen Queue-Länge und den Auswirkungen von Variabilität herzustellen, ist ein interessantes Konzept

• Es gibt auch Fälle, in denen ein Waterfall-Ansatz und Schätzungen in Zeiteinheiten gut funktionieren

  • In einem kleinen Professional-Services-Team wurden die Kundenanforderungen dokumentiert, mit dem Team besprochen und dann in Zeitspannen geschätzt
  • Nach Freigabe durch den Kunden folgten detailliertes Design, Entwicklung, QA und Release
  • Der Prozess hat sich in 20 Jahren nicht verändert, und das Team galt als sehr produktiv

• Story Points stehen nicht für Zeiteinheiten, sondern für relative Komplexität und Unsicherheit

  • Man sollte Stories auch mit großen Zahlen bewerten können
  • In manchen Teams werden nicht mehr als 7 Punkte vergeben
  • Anderswo wurden auch 21, 30 oder 50 Punkte vergeben

• Story Points waren eine grobe Zeiteinheit

  • Story Points auf eine eindeutige Zeiteinheit abzubilden, ist irreführend
  • Wichtig ist, vorherzusagen, wie viel Zeit Entwickler für eine Aufgabe aufwenden werden
  • Damit Queue-Analysen hilfreich sind, muss man die erwartete Zeit für jede Aufgabe kennen

• Als wir Scrum zum ersten Mal nutzten, verwendeten wir Rally

  • Story Points, geschätzte Zeit und tatsächliche Zeit wurden alle erfasst
  • Nach dem Wechsel zu Jira fiel die Zeiterfassung weg
  • Als die Zeitschätzungen genauer wurden, ließ sich die Arbeitslast im Team leichter ausbalancieren

• Story Points sind nützlich, wenn es darum geht, über die Komplexität von Arbeit zu sprechen, aber ungeeignet, um Geschwindigkeit zu messen

  • Als neuer Engineer habe ich viele Story Points abgearbeitet, aber das Management versuchte, das zu korrigieren
  • Es war schwierig, komplexe Aufgaben angemessen zu bewerten

• Softwareentwicklungsprojekte verlässlich zu schätzen, ist schwierig

  • Wichtig ist, die Arbeit gemeinsam mit dem Team in kleine Einheiten zu zerlegen und Zeitspannen zu schätzen
  • Ebenso wichtig ist es, im Verlauf des Projekts die Feature-Liste und neue Schätzbereiche zu berichten

• In Zeiteinheiten zu schätzen, ist die bessere Methode

  • Story Points werden am Ende doch in Zeiteinheiten umgerechnet
  • Es ist effizienter, die komplizierten Scrum-Prozesse zu vermeiden und die Arbeit einfach zu erledigen