Herkunft von Story Points
Erfunden hat sie Ron Jeffries, wie er selbst schreibt [1].
Das war zu einer Zeit, bei der mit XP dem Extreme Programming die User Storys noch in Zeiteinheiten geschätzt wurden.
Zunächst wurden die Zeiteinheiten in ideale Entwicklertage verwendet – also die Tage, an denen ein Entwickler wirklich störungsfrei arbeiten kann. Diese Tage wurden dann einfach “Points” oder “Story Points” genannt.
Ron Jeffries beantwortet die Frage, ob er die Erfindung der “Story Points” oder deren Missbrauch bedaure. Seine Antwort lautet:
- Ich bedauere ihren Missbrauch auf jeden Fall;
- Ich denke, sie zu verwenden, um vorherzusagen, „wann wir fertig sind“, ist bestenfalls eine schwache Idee;
- Ich denke, es ist bestenfalls verschwenderisch, nachzuverfolgen, wie sich die tatsächlichen Zahlen mit den Schätzungen vergleichen;
- Ich denke, der Vergleich von Teams hinsichtlich der Qualität der Schätzungen oder der Geschwindigkeit ist schädlich.
Warum Story Points statt Stunden schätzen?
Für Manager bedeutet die Existenz von Schätzungen eine Vergleichsmöglichkeit. Sind die Abweichungen von der Schätzung zu groß, fordern Manager genauere Schätzungen.
Dabei ist es im Agilen essenziell, die wertvollen Dinge zuerst und schnell zu erledigen. Der Fokus auf Points und Schätzungen lenkt vom zentralen Zweck von Agile, schnell echten Mehrwert zu liefern, ab.
Wenn Manager Zahlen zur Verfügung haben, bauen sie unweigerlich Druck auf. Dabei ist es nicht das Ziel immer mehr zu schaffen, sondern viele kleine Dinge zu liefern, die Mehrwert bieten, so Ron.
Weil die Points keine Skala haben, mit der sie sich vergleichen lassen, ist ein Vergleich über Teams unmöglich geworden.
Wie werden Story Points für Schätzungen verwendet?
Ich habe ich gelesen, dass Story Points Schätzen, in agilen Projekten unerlässlich, für die Verbesserung des Sprint-Managements und zur Steigerung der Produktivität im Team sind.
Dieses Verständnis über User Storys, ist meines Erachtens, maximal falsch!
Was sind Story Points?
Story Points sind dazu da, um den relativen Aufwand zwischen User Storys zu messen. Diese Messungen sind die Basis für die Planung von Releases in Scrum, auch für die Planung von Sprints.
Weil die Points keine Skala besitzen, können diese weder miteinander verrechnet werden noch für Vergleiche außerhalb des Teamkontexts herangezogen werden.
Story Points sind ein Maß für den relativen inhaltlichen Aufwand und nicht für Produktivität.
Sie stehen als relative Kennzahl weder im Vergleich mit anderen bereits geleisteten oder noch zu leistenden Arbeiten.
Wie werden Story Point agil berechnet?
In den meisten Fällen wählen Entwicklungsteams Werte aus der Fibonacci-Reihe.
Die Fibonacci-Reihe wird erzeugt, in dem die jeweils vorangegangen 2 Zahlen miteinander addiert werden.
Für die Bewertung von User Storys werden meist Zahlen bis 13 verwendet: 1, 2, 3, 5, 8, 13 [ 21, 34 …]
Warum die Fibonacci Reihe nicht für Story Points genügt
Gebräuchlicher ist jedoch die Cohn-Skala®, nach ihrem Erfinder, Mike Cohn [3]. Diese Werteskala ist mit 1, 2, 3, 5, 8, 13, 20, 40, 100 aufgebaut.
Die Begründung von Mike ist, dass der Abstand von 13 zu 21 in der Fibonacci-Reihe zu kurz ist, als dass er die steigende Unsicherheit beim Schätzen, verdeutlichen könnte. Außerdem täuschen Zahlen, die so dicht beieinander liegen, eine Präzision vor, die nicht erreicht werden kann.
Was Story Points mit dem Weberschen Gesetz zu tun haben
Die Größendifferenz auf der Cohn-Skala sind durch das Webersche Gesetz [4] beeinflusst. Das Webersche Gesetz besagt, um wie viel der Sinnesreiz steigen muss, damit ein Unterschied erkannt wird.
So ist ein Gewichtsunterschied eines in der ruhenden Hand befindlichen Objekts erst feststellbar, wenn sich das Gewicht um >= 2 % verändert. Wenn du 100 Gramm in der Hand hältst, benötigst du ein Gewicht von 98 oder 102 Gramm, um einen Unterschied feststellen zu können.
Wenn du 10 kg Gewicht in der Hand hast, benötigst du bereits 200 Gramm Differenz, um eine Wahrnehmung zu erzeugen.
Damit Story Points von ihrer Komplexität her, unterschiedlich wahrzunehmen, benötigen die größeren Werte, gemäß dem Weberschen Gesetz, einen höheren Abstand.
Wie viel ist ein Story Point wert?
Story Points verhalten sich anders als etwa Wasser. Wenn du einen Liter Wasser auf eine Waage stellst, dann wird diese 1 kg Gewicht anzeigen.
Wasser lässt sich auf einer Gewichtsskala mit Einheiten von Kilogramm, Gramm, Pfund oder Tonnen messen und einordnen.
Ein Liter Wasser wiegt überall auf dem Planeten 1 Kilogramm.
Story Points besitzen keine Skala mit Einheiten.
Um bei dem Vergleich mit dem Gewicht zu bleiben: Ein Story Point kann überall unterschiedlich viel wiegen! Jedes Team kann einem Story Point eine individuelle Menge an Komplexität oder Aufwand zuordnen.
Diese Zuordnung von Komplexität ist dem jeweiligen Kontext geschuldet und basiert eher auf Intuition anstelle einer Regel. Das ist der Grund, warum sich weder Teams noch Backlogs auf der Basis von Story Points miteinander vergleichen lassen.
7 Tipps für
bessere User Storys
Lese und nutze meine täglichen Agile-Tipps und
ich schenke dir mein E-Book
„User Story Secrets“
Du wirst damit kostenlos Abonnent meines exklusiven Agile Briefing, das du jederzeit wieder abbestellen kannst. Beachte unsere Datenschutzerklärung.
Wie mit Story Points Komplexität geschätzt wird
Wenn ich mit Teams arbeite, erlebe ich immer wieder, dass Komplexität und Kompliziert synonym und oft genug falsch verwendet werden. Deshalb erkläre ich kurz den wichtigen Unterschied:
Komplex versus Kompliziert
“Die Komplexität eines Systems steigt mit der Anzahl an Elementen, der Anzahl an Verknüpfungen zwischen diesen Elementen sowie der Funktionalität und Unüberschaubarkeit dieser Verknüpfungen.” [5]
Kompliziert ist etwas, wenn Ereignisse vorhersehbar sind. Diese Vorhersehbarkeit basiert auf einem erlernbaren Regelsystem. Ist das Regelsystem verstanden, ist es nicht mehr kompliziert [6].
Auf den Punkt gebracht: Komplexität beinhaltet unvorhersehbares Verhalten. Kompliziert ist etwas, das geregelt, aber “noch” nicht verstanden ist.
Story Points haben eine Verbindung zur Zeit
Das Problem beim Schätzen von Komplexität ist, wir Menschen können uns Komplexität gar nicht vorstellen. Schätzungen von Komplexität basieren eher auf ein Bauchgefühl, als auf Objektivität.
Weil das so ist, denken wir beim Schätzen komplexer Systeme in Zeit. Das Gefühl, wie viel Zeit das erledigen, einer Aufgabe benötigt, wird aus der Erfahrung der schätzenden Person abgeleitet.
Wenn in einem Team nun jeder basierend auf der individuellen Erfahrung schätzt, kann kein guter Schätzwert erzielt werden. Die Abweichungen sind dafür zu groß.
Im schlimmsten Fall einigt sich das Team auf einen Wert. Dieser Wert ist ein Kompromiss und ist für alle Teammitglieder falsch.
Relativität der Story Points
Um dieser Falle der Kompromisse zu entkommen, gibt es einen simplen Trick: Die Teilnehmer des Teams denken in Zeit und sprechen in Relationen.
Statt für Aufgabe A 1 Stunde oder B 2 Stunden zu sagen, denken sie das nur. Sagen müssen sie: Aufgabe B dauert doppelt so lange, wie Aufgabe A. Oder Aufgabe A dauert halb so lang, wie Aufgabe B.
Wie hängen Story Points und die Velocity zusammen?
Um die individuelle, nicht mit anderen Teams vergleichbare Entwicklungsgeschwindigkeit (Velocity) zu messen, werden die in einer Zeiteinheit umgesetzten Story Points historisch ausgewertet.
SUMME(SPZE1..SPZEn) / ZEn = VelocitySP
Dazu addiert man die Points der erledigten Zeiteinheiten und teilt diesen Wert durch die Anzahl der Zeiteinheiten. Dies ist die gemittelte Entwicklungsgeschwindigkeit.
Dieser Wert kann für die Planung der nächsten Zeiteinheit als Richtgröße eingesetzt werden.
Fazit
Story Points sind ideal für die Schätzung komplexer Aufgaben. In ihrer Relativität ermöglichen Story Points den Entwicklungsteams interdisziplinäre Schätzungen, ohne faule Kompromisse eingehen zu müssen.
Story Points fördern Diskussionen bei der Bewertung von Aufgaben. Sie geben agilen Teams ein Mittel an die Hand, um die Zusammenarbeit zu verbessern.
Die dunkle Seite des Mondes ist, dass Story Points von unerfahrenen Führungskräften missbraucht werden. Sie versuchen, mit Story Points Menschen und Teams in ihrer Leistung zu beurteilen. Selbst nach der Forderung von detaillierten Release-Plänen oder Projektplänen mit konkreten Terminen machen unerfahrene Führungskräfte nicht halt.
Auch Entwickler verfallen oft in unnötige Diskussionen, ob eine User Story 2 oder 3 Points hat.
Für eine Metrik ist der gelieferte Geschäftswert geeigneter. Auch über den Return on Invest (ROI) lässt sich messen, wie viel Geschäftswert, die gesamte Wertschöpfungskette zur Verfügung stellt.
Bleib erfolgreich. Damit es agil wird,
Frank Schatz
Quellenangaben:
- Ron Jeffries, 2019, Story Points revisited
- Fibonacci-Folge, Wikipedia
- Mike Cohn, Mountain Goat Software
- Wikipedia, Weber-Fechner-Gesetz
- P. Milling: Systemtheoretische Grundlagen zur Planung der Unternehmenspolitik. Berlin: Duncker & Humblot, 1981
- Frag den Lesch, ZDF Mediathek, Komplex oder Kompliziert-was macht den Unterschied?
