Was sind Story Points? Ein praktischer Leitfaden
Was Story Points bedeuten, warum agile Teams damit statt in Stunden schätzen, was die Forschung tatsächlich zeigt und wie man sie nutzt, ohne zu viel zu versprechen.
Ein Story Point ist eine Einheit für den relativen Aufwand, die ein Team einer Arbeit zuweist. Sie vereint deren Komplexität, Unsicherheit und Umfang, statt die benötigte Stundenzahl vorherzusagen. Teams vergleichen Aufgaben miteinander („Das ist ungefähr doppelt so viel Arbeit wie jenes“), anstatt eine konkrete Zeit zu prognostizieren. Punkte werden beim Planning Poker häufig mit einer Skala wie Fibonacci vergeben. Im Folgenden: Was sie wirklich messen, was die Forschung sagt und wie man sie nutzt, ohne zu viel zu versprechen.
Was ist ein Story Point?
Ein Story Point beantwortet eine Vergleichsfrage, keine absolute. Statt „Wie viele Stunden dauert das?“ fragt das Team: „Wie groß ist das im Vergleich zu Arbeit, die wir bereits kennen?“ Eine Aufgabe, die alle als klein einschätzen, könnte eine 2 sein, eine aufwendigere eine 5, eine große und unscharfe eine 13. Die Zahl steht nicht für eine feste Zeit. Sie bezeichnet eine gemeinsam eingeschätzte relative Größe.
Eine abstrakte Einheit trennt die Schätzung von der Geschwindigkeit einer einzelnen Person und vom Druck, sich auf einen Termin festzulegen. Eine Junior- und eine Senior-Entwicklerin brauchen womöglich unterschiedlich lange, können sich aber häufig darauf einigen, dass eine Aufgabe ungefähr doppelt so groß ist wie eine andere.
Woraus ein Story Point besteht
Drei Faktoren fließen in eine Zahl ein:
- Komplexität: Wie kompliziert die Arbeit ist, wie viele bewegliche Teile und betroffene Systeme es gibt.
- Unsicherheit: Wie viel das Team noch nicht weiß. Unbekanntes und Risiken erhöhen den Wert.
- Umfang: Wie viel wiederkehrende Arbeit anfällt, auch wenn jedes einzelne Stück einfach ist.
Darum können zwei Aufgaben, die ähnlich viele Stunden dauern würden, unterschiedliche Punktwerte erhalten. Eine einfache Änderung in vierzig Dateien und ein schwieriger Algorithmus in einer Datei sind beide „groß“, aber aus verschiedenen Gründen.
Warum Teams in Punkten statt Stunden schätzen
Die Beliebtheit relativer Schätzungen hat vor allem mit Menschen zu tun, nicht mit Mathematik:
- Sie entkoppeln die Schätzung von einzelnen Personen. Stunden hängen davon ab, wer die Arbeit erledigt. Relative Größen sollen zwischen Personen stabiler sein.
- Vergleichen geht schneller als Vorhersagen. Zu beurteilen, ob eine Aufgabe größer ist als eine andere, ist schneller als eine genaue Dauer vorherzusagen. Sitzungen kommen dadurch zügiger voran.
- Sie widerstehen Scheingenauigkeit. „13 Punkte“ benennt Unsicherheit ehrlich. „16,5 Stunden“ tut so, als gäbe es eine Genauigkeit, die niemand hat.
- Sie bringen die Diskussion in Gang. Das wichtigste Ergebnis gemeinsamer Schätzung ist nicht die Zahl, sondern das Gespräch, in dem verborgene Arbeit sichtbar wird – etwa in einer Planning-Poker-Sitzung.
Das sind echte Vorteile. Trotzdem sollte man auch über den Punkt sprechen, den viele Anleitungen auslassen.
Was die Forschung tatsächlich sagt
Die verbreitete Behauptung, Story Points seien genauer als Schätzungen in Stunden, wird durch kontrollierte Studien kaum gestützt.
In einer Reihe kontrollierter Experimente schätzten professionelle Entwickler dieselben Aufgaben auf zwei Arten: Einige vergaben Story Points, andere Arbeitsstunden. Die Story-Point-Schätzungen waren weniger genau als die Stundenschätzungen und dauerten länger – selbst bei Entwicklern mit viel Erfahrung mit Story Points. Dieselbe Forschung zeigte, dass sich die „Größe“ einer Aufgabe je nach schätzender Person stark änderte. Das widerspricht gerade der angeblichen Unabhängigkeit von der ausführenden Person.
Das Muster zeigt sich auch in großen Datensätzen. In einer Analyse von 2022 untersuchten Forschende 37.440 reale User Stories aus 37 Open-Source-Projekten und verglichen die Story Points mit der tatsächlichen Dauer. Nur bei etwa 7 % der Projekte entsprachen die Punkte dem tatsächlichen Aufwand gut. Bei den übrigen war der Zusammenhang mittelmäßig oder schwach; bei ungefähr drei von vier Stories wich die ursprüngliche menschliche Schätzung nach oben oder unten ab. Allgemeinere Übersichten zu agilen Schätzungen kommen zu einer abgeschwächten Version desselben Ergebnisses: Story Points sind eine der verbreitetsten Methoden, doch es gibt keine solide Evidenz, dass sie den Aufwand genau vorhersagen. (Vollständige Nachweise stehen unter „Quellen“.)
Die ehrliche Schlussfolgerung: Story Points sagen nicht zuverlässig voraus, wie lange eine einzelne Aufgabe dauert. Wer damit genaue Einzelprognosen erwartet, wird enttäuscht – und die Forschung erklärt, warum.
Wofür Story Points nützlich sind
Für vieles, solange du sie für die passende Aufgabe einsetzt:
- Gemeinsames Verständnis. Wenn Stimmen auseinandergehen, deckt die Diskussion Annahmen, fehlende Aufgaben und Risiken auf. Diese Abstimmung ist das eigentliche Ergebnis und macht den Aufwand lohnenswert.
- Grobe Vorhersagen über viele Aufgaben. Einzelne Schätzungen sind ungenau, aber über ein ganzes Backlog gleichen sich Fehler teilweise aus. Wie viele Punkte ein Team pro Sprint erledigt (seine Velocity), ergibt eine brauchbare grobe Prognose – deutlich besser als eine Summe geratener Stunden.
- Auf schwierige Aufgaben hinweisen. Eine 13 oder 21 ist ein Signal: Die Aufgabe ist zu groß oder zu unklar. Teile sie auf, bevor sie zum Problem wird.
- Menschlichere Schätzung. Relative Größen vermeiden Termindruck und individuelle Schuldzuweisung, die Stundenschätzungen begünstigen.
Nichts davon setzt voraus, dass Punkte den Aufwand exakt abbilden. Entscheidend ist, dass das Team spricht und konsequent vergleicht.
So schätzt du in Story Points
- Wähle eine Skala. Die meisten Teams nutzen einen Fibonacci-Kartensatz (0, 1, 2, 3, 5, 8, 13, 21). Die wachsenden Abstände spiegeln die zunehmende Unsicherheit wider und vermeiden Haarspalterei bei großen Aufgaben.
- Legt eine Referenz-Story fest. Einigt euch auf eine gut verstandene Aufgabe als Anker („Das ist unsere 3“). Alles andere wird damit verglichen.
- Schätzt und deckt gemeinsam auf. Nutzt Planning Poker, damit niemand sich an der zuerst genannten Zahl orientiert. Die vollständige Methode erklärt unsere Schritt-für-Schritt-Anleitung.
- Schätzt neu, wenn ihr mehr wisst. Punkte sind eine Momentaufnahme des aktuellen Verständnisses, kein Vertrag. Aktualisiert sie, wenn sich die Sachlage ändert.
Story Points im Vergleich zu Stunden
| Aspekt | Story Points (relativ) | Stunden (absolut) |
|---|---|---|
| Was gemessen wird | Relative Größe (Komplexität, Unsicherheit, Umfang) | Eine bestimmte Dauer |
| Abhängig davon, wer die Arbeit erledigt | Soll es nicht sein | Ja |
| Für Prognosen einzelner Aufgaben geeignet | Nein (schwache Evidenz) | Teilweise, bei kleinen, bekannten Aufgaben |
| Für Teamprognosen geeignet | Ja, über viele Aufgaben und die Velocity | Schwer zuverlässig zu addieren |
| Schätzgeschwindigkeit | Vergleich geht schnell | Prognose dauert länger |
| Hauptwert | Gemeinsames Verständnis und Diskussion | Konkrete Zahl, wenn sie wirklich benötigt wird |
Keine der beiden Methoden ist Zauberei. Wenn eine interessierte Person tatsächlich ein Datum braucht, reichen Punkte allein nicht aus. Velocity-Trends und ein Gespräch bringen euch näher ans Ziel als ein Stapel geratener Stunden.
Häufige Fehler und Fehlanwendungen
- Punkte in Stunden umrechnen. Eine Tabelle „1 Punkt = 4 Stunden“ macht den Grund für Punkte zunichte und führt Scheingenauigkeit wieder ein.
- Velocity verschiedener Teams vergleichen. Punkte werden pro Team kalibriert. Die 8 von Team A ist nicht die 8 von Team B. Velocity als Produktivitätsrangliste zu nutzen, ist ein bekanntes Anti-Pattern.
- Punkte als Leistungskennzahl behandeln. Sobald Punkte zum Ziel werden, werden sie aufgebläht und verlieren ihre Bedeutung (Goodharts Gesetz in der Praxis).
- Genauigkeit für einzelne Aufgaben erwarten. Wie die Forschung zeigt, sagen Punkte den tatsächlichen Zeitaufwand einer einzelnen Aufgabe nur schwach voraus. Prognostiziere über viele Aufgaben, nicht über eine.
- Nie neu schätzen. Vor dem Verständnis der Arbeit vergebene Punkte sind nicht in Stein gemeißelt. Aktualisiere sie.
Häufig gestellte Fragen
Sind Story Points dasselbe wie Stunden?
Nein. Stunden sind eine absolute Dauer, die an eine bestimmte Person gebunden ist. Story Points bezeichnen eine relative Größe aus Komplexität, Unsicherheit und Umfang und sollen unabhängig davon sein, wer die Arbeit erledigt.
Wie viele Stunden entspricht ein Story Point?
Es gibt keine feste Umrechnung; eine solche festzulegen, widerspricht dem Zweck. Manche Teams beobachten im Nachhinein, dass ein Punkt bei ihnen meist einer bestimmten Zeitspanne entspricht. Das ist ein Muster, aber keine Schätzregel.
Welche Skala sollten wir für Story Points verwenden?
Am verbreitetsten ist Fibonacci (0, 1, 2, 3, 5, 8, 13, 21), weil die wachsenden Abstände zunehmende Unsicherheit bei größeren Aufgaben widerspiegeln. T-Shirt-Größen eignen sich für eine schnelle grobe Schätzung.
Sind Story Points tatsächlich genau?
Für die Vorhersage des Aufwands einzelner Aufgaben ist die Evidenz schwach: Kontrollierte Studien belegen keinen klaren Genauigkeitsvorteil gegenüber Stunden, und groß angelegte Analysen zeigen nur einen uneinheitlichen Zusammenhang mit dem tatsächlichen Aufwand. Ihr Wert liegt im gemeinsamen Verständnis und in groben Prognosen über viele Aufgaben, nicht in präzisen Einzelvorhersagen.
Kann man die Velocity verschiedener Teams vergleichen?
Nein. Punkte werden innerhalb eines Teams kalibriert, daher sind die Velocities verschiedener Teams nicht vergleichbar. Ein Vergleich als Rangliste fördert aufgeblähte Punktwerte und ist ein verbreitetes Anti-Pattern.
Wer vergibt Story Points?
Gemeinsam die Personen, die die Arbeit erledigen werden, normalerweise in einer Planning-Poker-Sitzung. Die Product Ownerin oder der Product Owner klärt den Umfang, legt aber keine Zahl fest; der Scrum Master moderiert.
Messen Story Points Aufwand oder Komplexität?
Beides – zusätzlich zu Unsicherheit und Umfang. Mehrere Faktoren fließen in eine relative Zahl ein. Deshalb können zwei Aufgaben mit ähnlichem Zeitaufwand verschiedene Punktwerte haben.
Quellen
- Usman, M., Mendes, E., Weidt, F. & Britto, R. (2014). Effort estimation in agile software development: a systematic literature review. PROMISE 2014.
- Jørgensen, M. & Escott, E. Relative estimates of software development effort: are they more accurate or less time-consuming to produce than absolute estimates? (Kontrollierte Experimente mit professionellen Entwicklern.)
- Tawosi, V., Moussa, R. & Sarro, F. (2022). On the Relationship Between Story Points and Development Effort in Agile Open-Source Software. ESEM 2022 (37.440 User Stories, 37 Projekte).
- Pasuksmit, J., Thongtanunam, P. & Karunasekera, S. (2022). Story points changes in agile iterative development. Empirical Software Engineering.
Weiterlesen
Planning-Poker-Online-Statistiken: Wie viele Teams es wirklich nutzen
Keine Umfrage zählt direkt, wie viele Menschen Planning Poker online nutzen. Hier sind die echten Daten (State of Agile, akademische Studien) und eine ehrliche Schätzung daraus.
Weiterlesen →Agile Schätzmethoden im Vergleich
Planning Poker, T-Shirt-Größen, Bucket-System und Affinitätsschätzung im Vergleich: Was die Forschung sagt und wie du die passende Methode auswählst.
Weiterlesen →