Was sind Story Points?
Story Points werden genutzt, um die Größe von User Stories zu definieren. Sie beschreiben den Entwicklungsaufwand, der notwendig ist, um neue User Stories auszuliefern. Dabei sollte das Entwicklungs-Team vor der ersten Schätzung festlegen, welche Dimensionen bei der Schätzung berücksichtigt werden. Das können folgende sein:
- Menge der Arbeit
- Komplexität der Arbeit
- Risiko bei der Implementierung von Innovationen
- Ungewissheit bei der Umsetzung
Es ist wichtig zu betonen, dass es sich bei Story Points um eine Schätzung handelt. Der Anspruch ist nicht, dass eine perfekte Zahl abgeliefert wird, sondern es sollte mehr als Lerngelegenheit für das Team verstanden werden, um bei zukünftigen Schätzungen besser zu werden.
Wozu braucht man Story Points?
Story Points sind ein sinnvolles Mittel für ein agiles Team, damit es abschätzen kann, wie viel Arbeit es in der nächsten Iteration schaffen könnte. Dabei kann es ein Ziel sein, die durchschnittliche Velocity (Menge erledigter Arbeit) pro Iteration zu ermitteln und den Fortschritt des Teams in der Iteration, durch z.B. Burndown-Charts, transparent zu machen.
Wie funktioniert das Schätzen?
Zur Schätzung wird meist eine angepasste Fibonacci-Zahlenreihe genutzt. Sie besteht aus den Werten 1, 2, 3, 5, 8, 13, 20, 40 und 100. Man nutzt sie, damit die Schätzung leichter fällt, denn es sind relative Werte und keine lineare Abfolge.
Das Team sollte sich zu Beginn eine User-Story heraussuchen, die als Referenz dient. Wenn diese Story beispielsweise mit einer 5 geschätzt wird, können sich alle zukünftigen Schätzungen an dieser Story orientieren. Das macht eine Einordnung häufig leichter.
Um Schätzungen im Planning durchzuführen, wird häufig Planning Poker als Methode angewandt. Wenn das Team zusammen in einem Raum arbeitet, kann man mit Planning Poker Karten arbeiten. Falls das Team räumlich verteilt arbeitet, empfehle ich das Online-Tool Votingpoker.
Das Schätzen ist in jedem Fall die Arbeit des Teams. Niemand außer den Mitgliedern des Teams, welches die Arbeit an den Stories durchführt, sollte eine Schätzung abgeben bzw. diese beeinflussen. Das Team sollte den Schätzprozess als Gelegenheit zum Lernen sehen, um in Zukunft besser einschätzen zu können, wie viel Wert in einer Iteration ausgeliefert werden kann.
Fünf schädliche Anti-Patterns
In meiner Arbeit beim Kunden sind mir bereits diverse Anti-Patterns über den Weg gelaufen. Damit sind Verhaltensmuster gemeint, die ungünstig oder schädlich für den Erfolg und die Motivation des Teams sind. Ich möchte hier kurz auf die fünf aus meiner Sicht kritischsten Verhaltensmuster eingehen.
Mapping auf Manntage
Ab und zu versuchen z.B. Projektmanager, die aus der Welt des Wasserfall-Projektmanagements kommen, eine Umrechnung von Story Points auf Manntage vorzunehmen. Das passiert aus Gründen der Planungs-Illusion und damit eine gefühlte Kontrolle ausgeübt werden kann. Eine Umrechnung bedeutet immer zusätzlicher Aufwand, der nicht notwendig ist. Vielleicht wäre es klüger, sich im Team direkt auf eine Schätzung in Manntagen zu einigen. Alternativ kann dem Projektmanager erklärt werden, worin der Mehrwert einer relativen Schätzung liegt.
Framing durch den Product Owner
Es kann vorkommen, dass der Product Owner oder eine andere Person außerhalb des Entwicklerteams versucht, Einfluss auf die Schätzung zu nehmen, mit Aussagen wie: „Die Story ist höchstens eine 3“. Hierbei wird das Entwicklerteam in eine Richtung geframt. Es sollte jedoch immer darum gehen, dass nur die Personen die Schätzung beeinflussen, die tatsächlich die Umsetzung vornehmen können.
Vergleich von Teams
Ein schlimmes Anti-Pattern ist der Missbrauch der Story Points oder der Velocity, um verschiedene Teams miteinander zu vergleichen. Da Story Points eine relative Schätzmethode sind, wird sich in jedem Team eine andere Schätzdynamik entwickeln und andere Referenzen ausprägen. Wenn man Teams also komplett demotivieren will, dann ist das der richtige Weg.
Vorschätzung durch externe Stakeholder
Auch interessant ist, wenn die Stories schon durch externe Stakeholder vorgeschätzt werden und das Entwickler-Team dann „nur noch“ seine aktualisierte Schätzung liefern muss. Auch hier passiert ein Framing, welches einen Einfluss auf die Schätzung hat und zudem gerät das Team unter Rechtfertigungsdruck, wenn es der Meinung ist, dass mehr Story Points benötigt werden, als durch die externe Person vergeben wurden.
Als wichtigstes Fortschrittsmaß nutzen
Was ist das wichtigste Fortschrittsmaß für ein agiles Team? Wie viele Story Points in den Iterationen geschafft werden, oder? Bitte nicht! Auch das Agile Manifest definiert in seinem 7. Prinzip, dass funktionierende Software das wichtigste Fortschrittsmaß ist! Es geht doch darum, den Kunden durch gute und funktionierende Ergebnisse zu überzeugen. Passen Sie auf, welche KPIs Sie nutzen. Wenn Sie Story Points nutzen, hat das mit Sicherheit negative Auswirkungen auf die Motivation des Teams und damit auch auf ihre Performance.
Fazit und #NoEstimates Bewegung
Wenn ich als Scrum Master oder Agile Coach beim Kunden agiere, dann bringe ich meinen Teams gern das Konzept von Story Points, Schätzen und Planning Poker bei. Ich überlasse es jedoch immer dem Team, ob es das Konzept nutzt, weil es dem Team nützt oder ob es sich dagegen entscheidet.
Ich finde, Story Points können sinnvoll sein, wenn sie das Team voranbringen. Da ich allerdings bereits auf sehr viele Anti-Pattern in der Praxis gestoßen bin, die sich negativ auf die Motivation und die Performance des Teams auswirken können, bin ich auch Kritiker von Story Points. Es ist wirklich wichtig zu verstehen, warum man damit schätzt und sich als Team regelmäßig zu reflektieren, ob man noch auf dem richtigen Weg ist.
Ron Jeffries, einer der Begründer von Xtreme Programming und der Erfinder von Story Points, hat 2019 einen Blog-Artikel veröffentlicht, indem er sich für den Schmerz entschuldigt, den viele Entwickler-Teams durch falsche Nutzung von Story Points erleiden mussten. Das macht er aufgrund der vielen Anti-Patterns, die sich in Bezug auf die Nutzung von Story Points entwickelt haben.
Zudem hat sich in den letzten Jahren eine #NoEstimates Bewegung in der agilen Community gebildet. Die Bewegung rät dazu auf Schätzungen zu verzichten, wenn es möglich ist, da sie keinen direkten Wert liefern.
Abschließend lässt sich sagen, dass Story Points sowohl Vor- als auch Nachteile haben. Wenn sich ein Team entscheidet Story Points zu nutzen, sollte es auf mögliche Stolperfallen aufmerksam gemacht werden. Benötigen Sie einen Agile Coach oder Scrum Master, der sie bei der Einführung von Story Points unterstützt? Dann senden Sie mir eine Anfrage.
