Grandios verschätzt?! - Warum Story Points oft falsch verstanden werden – und wie sie Product Ownern wirklich helfen können

Schätzungen geben Orientierung. Sie helfen Teams dabei, ein gemeinsames Verständnis davon zu entwickeln, wie groß und aufwendig eine Aufgabe ist. Entwickler können sich bei sinnhafter Schätzung auf einen Sprint „committen“. Somit erhöhen Schätzungen die Selbstorganisation des Teams. Und Schätzungen ermöglichen Product Ownern, Erwartungen an Stakeholder zu steuern sowie die Planbarkeit eines Produktes. 

Gleichzeitig zeigt die Erfahrung: Schätzungen sind selten exakt. Mike Cohn sagt dazu treffend: 

“You’re trying to predict the future. And you’re usually wrong.” 

Das Hauptproblem: Wir versuchen, zukünftigen Aufwand vorherzusehen und das unter Bedingungen, die sich oft ändern. Komplexität, Unsicherheiten und unklare Anforderungen führen zu großen Abweichungen zwischen Schätzung und Realität. 

Und dennoch schätzen wir. Nicht, weil wir glauben, die Zukunft exakt vorhersagen zu können, sondern weil der Prozess des Schätzens uns hilft, besser über die Arbeit zu sprechen und diese zu verstehen. 

Viele Teams steigen von Zeitschätzungen (Stunden, Tage) auf Story Points um, weil sie merken, dass Zeit allein nicht reicht, um Aufwand realistisch einzuschätzen. Story Points bilden mehrdimensionalen Aufwand ab. Dies sind typischerweise die folgenden drei Aspekte: 

• Aufwand – Wie viel Arbeit steckt in der Story? 
• Komplexität – Wie schwierig ist sie technisch/fachlich? 
• Risiko/Unsicherheit – Gibt es offene Fragen oder unklare Anforderungen? 

Stell dir vor, ein Maler soll ein Zimmer streichen. 

• Aufwand: Wie viele Quadratmeter sind zu streichen? 
• Komplexität: Viele Fenster, Dachschrägen oder schwer zugängliche Stellen? Muss etwas zusätzlich abgeklebt oder geschützt werden? Sind Möbel zu verrücken? 
• Risiko: Ist der Kunde mit der Farbe wirklich sicher, oder wird evtl. nochmal gestrichen? 

Die reine Zeitangabe greift zu kurz. Story Points bilden die Gesamtsituation besser ab und erlauben so eine ganzheitlichere Bewertung. Genau das ist ihr Vorteil. 

Wie man eine solche User Story richtig schreiben würde findest du hier: User Storys - So schreibt man Geschichte(n)

Die Methode Planning Poker (auch Scrum Poker genannt) unterstützt Teams dabei, Schätzungen kollaborativ und gleichberechtigt abzugeben. Jeder schätzt individuell, dann wird gemeinsam verglichen und diskutiert. Die kollektive Intelligenz wird genutzt. Häufige Grundlage: eine modifizierte Fibonacci-Folge (1, 2, 3, 5, 8, 13, 20, …). 

Der Ablauf in Kürze: 

• Jede*r im Team erhält ein Kartenset mit Zahlen (meist in Fibonacci-Folge). 
• Eine User Story wird vorgestellt. 
• Alle wählen gleichzeitig eine Karte ... und decken sie gemeinsam auf. 
• Abweichungen werden diskutiert, um ein gemeinsames Verständnis zu entwickeln. 

Je größer der Aufwand, desto größer auch die Unsicherheit. Es besteht ein höheres Risiko mehr Zeit an einer Story zu verbringen als geschätzt. Die Fibonacci-Folge wächst nicht linear, was genau diese zunehmende Unschärfe spiegelt. Da jede Fibonacci Zahl weiter von der anderen entfernt ist, lässt sich einfacher erkennen um wieviel komplexer eine Story im Vergleich zu einer anderen ist, im Gegensatz zu fortlaufenden Nummern. Man kann einfacher sagen, diese Aufgabe ist doppelt so schwer als eine genaue Stundenschätzung zu nennen. 

Wenn eine Story auf 13 oder gar 40 Punkte geschätzt wird, ist das oft ein Warnsignal: 

• Ist die Story zu groß?  
  Die Story sollte in jedem Falle in den Sprint passen, um Abhängigkeiten zu reduzieren und die Planbarkeit sicherzustellen. 
• Ist sie zu unklar?  
  Jeder im Entwicklerteam, sollte die Story ausreichend verstanden haben. Fehlende Detaillierungsgrade und Anforderungen sollten ergänzt werden. 
• Gibt es versteckte Abhängigkeiten?  
  Abhängigkeiten sollten vorab aufgelöst oder klar kommuniziert werden. 

Große Storys gehören erklärt und geschnitten, nicht geschätzt. Je größer eine Story ist und je länger etwas dauert, desto größer ist das Risiko, dass es noch länger dauern kann, wegen unvorhergesehener Themen. Das ist eine wichtige Erkenntnis für Product Owner. 

Die Karten werden verdeckt gespielt, unter anderem um den sogenannten Ankereffekt zu vermeiden. Wenn der erste Entwickler „20“ sagt, denken viele automatisch in großen Dimensionen. Gleichzeitig aufzudecken, schützt vor dieser Verzerrung und bringt ehrliche Unterschiede zum Vorschein. Unterschiede, die Diskussionen auslösen und so zu einem besseren gemeinsamen Verständnis führen. 

Story Points sind eine abstrakte Größe. Neben Fibonacci gibt es weitere kreative Alternativen: 

• T-Shirt-Größen (XS, S, M, L, XL, XXL) 
• Tiere (Mücke bis Elefant) 
• Zeiteinheiten (wenn es wirklich sinnvoll ist) 
• Kinderschokolade-Größen (von Schokobon bis Weihnachtsmann) 

Wichtig ist: Das Team muss sich auf eine einheitliche Skala einigen und sie konsistent anwenden. 

Ein häufiger Irrglaube: Story Points dienen der Leistungsmessung. Das ist weder vorgesehen noch sinnvoll. Velocity ist kein KPI, sondern ein Planungshilfsmittel, um zu sehen, wie viel das Team in einem Sprint typischerweise schafft. Und auch das nur, wenn die Stories vergleichbar geschätzt wurden. Hat sich ein Team und die Velocity „eingeschwungen“ kann es als Indikator für eine Roadmap, z.B. in einer User Story Map, verwendet werden. 

Mit wachsender Erfahrung erscheinen ähnliche Aufgaben oft leichter. Eine Story, die vor drei Monaten noch 8 Punkte bekam, bekommt heute vielleicht nur noch 3. Das verzerrt die Vergleichbarkeit über die Zeit. 

Lösung: Etabliere Referenz-Stories. Also typische, gut dokumentierte User Stories aus der Vergangenheit, an denen sich neue Stories orientieren können. Das schafft Konsistenz und damit bessere Planbarkeit.  

Ein häufiger Fehler ist es, alles schätzen zu wollen. Dabei lohnt sich ein differenzierter Blick. Folgende Erfahrungswerte haben sich in vielen unserer Projekte etabliert: 

• Epics: Wenn benötigt nur grob schätzen, bspw. zur Roadmap-Planung (T-Shirt-Größen). 
• User Stories: Ja, idealerweise in Story Points. Sie sind die Basis für Sprintplanung und Kapazitätsabschätzung. 
• Defects: Analog zu User Stories sollten auch Defects geschätzt werden, so dass sie regulär eingeplant werden können.
• Tasks: Nicht zwingend. Tasks sind ein technisches Mittel zur Umsetzung, aber selten aussagekräftig für Business-Planung. Wenn ein Team mag, kann es in Stunden schätzen muss es aber nicht. Mike Cohn sagt dazu treffend: “Tasks should not be estimated. But if the team feels it helps, then let them.” 

Einige Teams arbeiten inzwischen bewusst ohne Schätzungen, z.B. mit NoEstimates-Ansätzen. Das kann funktionieren, wenn Stories klein genug geschnitten und konstant in etwa gleich groß sind. Auch hier sollte in irgend einer Art und Weise sichergestellt werden, dass über die User Story und das gemeinsame Verständnis gesprochen wird. Aber: Für die übergreifende Planung auf Produkt-Ebene fehlen dann oft die notwendigen Größenvergleiche. 

Für Product Owner, die Forecasts, Priorisierung und Roadmaps erstellen müssen, sind Story Points (oder eine andere geeignete Schätzmethode) oft das praktikablere Werkzeug.  

Gute Schätzungen sind weniger eine Zahl als ein Gespräch. Wenn beim Planning Poker diskutiert wird, warum jemand eine hohe Zahl wählt, entstehen oft genau die Einsichten, die vorher gefehlt haben: Risiken, Unklarheiten, fehlende Akzeptanzkriterien. 

Für dich als Product Owner heißt das: Nutze Schätzungen nicht, um das Team zu kontrollieren, sondern um das gemeinsame Verständnis zu verbessern. Gute Schätzungen entstehen nicht durch ausgeklügelten Schätzungsverfahren, sondern durch bessere Kommunikation und die ehrliche Erfahrung der Entwickler. 

Wie geht dein Team mit Story Points um? Gibt es Referenz-Stories? Hast du schon mal mit alternativen Schätzmethoden experimentiert - oder komplett aufs Schätzen verzichtet? Teile gerne deine Erfahrungen in den Kommentaren. 

Zu welchem Thema möchtest du noch mehr hören?  

 ---