User Story Training
by Frank Schatz

Story Points – Eine Definition

Inhalt

Herkunft von Story Points

Damals hat vermutlich Ron Jeffries, wie er selbst schreibt [1], Story Points erfunden. Das war zu einer Zeit, bei der mit XP dem Extreme Programming die User Stories 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:

  1. Ich bedauere ihren Missbrauch auf jeden Fall;
  2. Ich denke, sie zu verwenden, um vorherzusagen, „wann wir fertig sind“, ist bestenfalls eine schwache Idee;
  3. Ich denke, es ist bestenfalls verschwenderisch, nachzuverfolgen, wie sich die tatsächlichen Zahlen mit den Schätzungen vergleichen;
  4. Ich denke, der Vergleich von Teams hinsichtlich der Qualität der Schätzungen oder der Geschwindigkeit ist schädlich.

Story Point Missbrauch

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 Story 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.

Story Points für Schätzungen verwenden

Irgendwo habe ich gelesen, dass Story Points schätzen, in agilen Projekten unerlässlich für die Verbesserung des Sprint-Managements und zur Steigerung der Teamproduktivität sind.

Dieses Verständnis über User Stories, ist meines Erachtens, maximal falsch!

Was sind Story Points?

Story Points sind dazu da, um den relativen Aufwand zwischen User Stories zu messen. Diese Messungen sind die Basis für die Planung von Releases in Scrum auch für die Planung von Sprints.

Weil Story Points keine Skala besitzen, können diese weder miteinander verrechnet werden noch für Vergleiche außerhalb des Teamkontext herangezogen werden.

Story Points sind ein Maß für den relativen inhaltlichen Aufwand. Story Points sind nicht als Maß für Produktivität geeignet, sondern als relative Kennzahl im Vergleich mit anderen bereits geleisteten oder noch zu leistenden Arbeiten.

Welche Werte können Story Points annehmen?

In den meisten Fällen weisen Entwicklungsteams Story Points Werte aus der Fibonacci-Reihe zu. Die Fibonacci-Reihe wird erzeugt in dem die jeweils vorangegangen 2 Zahlen miteinander addiert werden. Die Fibonacci-Reihe startete ursprünglich mit 0, 1, 1.

Für die Bewertung von Story Points wird die Fibonacci-Reihe[2] meist bis 13 angewendet: 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 Werte Skala 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 wieviel 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 ein 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.

Story Points: Skala ohne Einheit

Weil die Schätzungen ohne Skala erfolgt, haben sich auch Schätzungen nach Konfektionsgrößen XS, S, M, L, XL … oder Tiere: Maus, Katze, Hund … bewährt.

Story Points verhalten sich anders als zum Beispiel 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. Dieser 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, das Story Points verwendet, 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.

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 wieviel 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 Kompromiß 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 relativ.

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.

Entwicklungsgeschwindigkeit (Velocity) mit Story Points messen

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 erledigten Story Points der 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 Roadmaps mit konkreten Terminen machen unerfahrene Führungskräfte nicht halt.

Der gelieferte Wert von Features ist viel geeigneter. Über den Return on Invest (ROI) lässt sich sehr leicht messen, wie viel Wert, mit welchem Impact, die gesamte Wertschöpfungskette zur Verfügung stellt.

Bleib Gesund!

Frank Schatz,

damit es agil wird.

Quellenangaben:

  1. Ron Jeffries, 2019, Story Points revisited
  2. Fibonacci-Folge, Wikipedia
  3. Mike Cohn, Mountain Goat Software
  4. Wikipedia, Weber-Fechner-Gesetz
  5. P. Milling: Systemtheoretische Grundlagen zur Planung der Unternehmenspolitik. Berlin: Duncker & Humblot, 1981
  6. Frag den Lesch, ZDF Mediathek, Komplex oder Kompliziert- was macht den Unterschied?
Share on facebook
teilen
Share on twitter
twittern
Share on pinterest
pinnen
Share on linkedin
LinkedIn
Share on xing
xingen
Frank Schatz

Frank Schatz

ist geprüfter Sachverständiger für agiles Projektmanagement, agiler Trainer, zertifizierter Scrum Master und Certified Instructor. Frank fokussiert sich auf die Reparatur agiler Projekte und dem Schreiben besserer User Stories.
Sein Motto: Menschen größer werden lassen.

User Story Zertifizierung

Certified User Story Professional

Beschleunige deine Karriere und erschaffe bessere Produkte.