Agile Schätzung mit Story Points: relativ statt absolut

Warum relativ statt absolut geschätzt wird

Der Ausgangspunkt der Story-Point-Idee ist eine Beobachtung über menschliches Schätzen: Wir sind schlecht darin, absolute Zeiten zu schätzen («das dauert 6,5 Stunden»), aber gut darin, relative Grössen zu vergleichen («das ist etwa doppelt so aufwändig wie jenes»). Story Points nutzen diese Stärke: Statt zu fragen «wie lange dauert das?» fragen sie «wie gross ist das im Vergleich zu anderem?». Eine kleine, klare Aufgabe bekommt wenige Punkte, eine grosse, komplexe oder unsichere viele — wobei Story Points bewusst mehrere Dimensionen bündeln: Aufwand, Komplexität und Unsicherheit zusammen. Das ist realistischer als reine Zeitschätzung, denn eine Aufgabe kann wenig Aufwand, aber hohe Unsicherheit haben, und beides beeinflusst, wie «gross» sie sich anfühlt. Der Verzicht auf absolute Zeit hat noch einen Vorteil: Er entkoppelt die Schätzung von der Person (was für den einen 4 Stunden sind, ist für die andere 8 — die relative Grösse ist stabiler) und nimmt den Druck aus der Schätzung, weil keine verbindliche Zeitzusage entsteht.

Von Punkten zur Vorhersage: Velocity

Story Points allein sagen noch nichts über Termine — die Brücke ist die Velocity: die Zahl der Story Points, die ein Team pro Sprint tatsächlich abschliesst. Sie wird nicht geschätzt, sondern gemessen: Nach einigen Sprints weiss das Team empirisch, dass es etwa X Punkte pro Sprint schafft. Damit lässt sich vorhersagen, wie viele Sprints ein Backlog von bekannter Punktzahl braucht — eine empirische, sich selbst korrigierende Planung statt einer optimistischen Vorabschätzung. Das ist die eigentliche Kraft des Systems: Es plant auf Basis dessen, was das Team wirklich leistet, nicht dessen, was es sich vornimmt. Wichtig ist, dass die Velocity teamspezifisch ist — sie hängt von der Zusammensetzung, dem Kontext und der Definition der Punkte ab und lässt sich nicht zwischen Teams vergleichen. Das Team-A mit Velocity 30 ist nicht «besser» als Team-B mit Velocity 20; ihre Punkte bedeuten schlicht Verschiedenes. Wer Velocities zwischen Teams vergleicht, hat das System missverstanden.

Planning Poker: gemeinsam schätzen

1. 01
   Unabhängig schätzenJedes Teammitglied schätzt eine Aufgabe unabhängig (etwa mit Karten), bevor die Werte aufgedeckt werden — das verhindert, dass sich alle am ersten Wert oder an der lautesten Stimme orientieren (Ankereffekt).
2. 02
   Abweichungen diskutierenDer eigentliche Wert liegt in den Abweichungen: Wenn einer 3 und ein anderer 13 schätzt, haben sie unterschiedliches Verständnis der Aufgabe — die Diskussion deckt Missverständnisse, versteckte Komplexität oder fehlendes Wissen auf. Das Gespräch ist wichtiger als die Zahl.
3. 03
   Konsens findenNach der Diskussion wird neu geschätzt, bis ein tragfähiger Konsens entsteht. Nicht der Durchschnitt, sondern das gemeinsame Verständnis zählt.
4. 04
   Referenzaufgaben nutzenEine bekannte Aufgabe als Anker («das ist eine 5») erleichtert die relative Einordnung neuer Aufgaben — relatives Schätzen braucht Bezugspunkte.

Die typischen Fehler mit Story Points

Story Points werden häufig missbraucht, und jeder Missbrauch zerstört ihren Sinn. Der häufigste: die Umrechnung in Stunden («ein Punkt = 4 Stunden»). Damit macht man aus der relativen Schätzung wieder eine absolute Zeitschätzung und verliert alle ihre Vorteile — die Entkopplung von der Person, die Bündelung von Unsicherheit, die Empirie der Velocity. Der zweite: Story Points als Leistungsmassstab. Sobald Velocity zur Kennzahl wird, an der Teams gemessen werden, blähen sie ihre Schätzungen auf (Point-Inflation), und die Zahlen werden wertlos — Velocity ist ein Planungswerkzeug für das Team, kein Kontrollinstrument für das Management. Der dritte: Velocities zwischen Teams vergleichen, was mangels gemeinsamer Punktdefinition sinnlos ist. Der vierte: zu viel Aufwand ins Schätzen stecken — Story Points sollen schnell gehen; wer stundenlang über einzelne Schätzungen debattiert, verfehlt den Zweck. Richtig verstanden sind Story Points ein pragmatisches, entlastendes Werkzeug; falsch verstanden werden sie zur Bürokratie mit Kontrollcharakter. Und für manche Teams ist die ehrlichste Erkenntnis, dass sie Story Points gar nicht brauchen — wer stabil kleine, ähnliche Aufgaben hat, kann auch einfach Aufgaben zählen. Das Werkzeug dient dem Team, nicht umgekehrt.

Diese Methode lässt sich in einem Projekt-Tool wie Flenio direkt abbilden — DACH-nativ und DSG-konform gehostet.

Häufige Fragen

Welche Skala soll man für Story Points nehmen?

Verbreitet ist eine an Fibonacci angelehnte Reihe (1, 2, 3, 5, 8, 13, …), weil die wachsenden Abstände die zunehmende Unsicherheit bei grösseren Aufgaben abbilden — grosse Dinge lassen sich nicht fein unterscheiden. Die genaue Skala ist zweitrangig; wichtig ist, dass das Team sie konsistent nutzt und ein gemeinsames Verständnis der Werte hat.

Wie lange dauert es, bis die Velocity aussagekräftig ist?

Meist einige Sprints (grob drei bis fünf), bis sich ein stabiler Wert einpendelt — vorher schwankt sie zu stark für verlässliche Vorhersagen. Und sie bleibt eine sich anpassende Grösse: Änderungen im Team, im Kontext oder in der Arbeitsart verschieben sie. Velocity ist ein empirischer Trend, keine feste Konstante.

Sind Story Points besser als Stundenschätzungen?

Für die agile Sprintplanung im eingespielten Team oft ja — sie sind schneller, entkoppeln von der Person und ermöglichen empirische Planung über Velocity. Für Verträge, Budgets und externe Zusagen braucht es am Ende trotzdem eine Übersetzung in Aufwand und Kosten. Beide haben ihren Platz; entscheidend ist, sie nicht zu vermischen (also Story Points nicht heimlich als Stunden zu behandeln).