Story Points: So schätzen Sie Agile-Arbeit (mit Beispielen)

Story Points bringen fast jedes Team beim ersten Kontakt ins Straucheln. Es sind keine Stunden. Es sind keine Tage. Und trotzdem nutzen Teams sie, um Lieferungen vorherzusagen, Sprints zu planen und zu entscheiden, ob ein Feature dieses oder nächstes Quartal live geht.

Wenn Sie als Manager oder Director versuchen, mehr Planbarkeit in einen agilen Workflow zu bringen, führt an Story Points kein Weg vorbei. Dieser Leitfaden erklärt, was sie sind, warum sie funktionieren, wie Sie Schätz-Sessions durchführen und worauf Sie achten sollten.

Was sind Story Points?

Ein Story Point ist eine relative Einheit, mit der der Gesamtaufwand für die Umsetzung einer Arbeit gemessen wird. "Aufwand" umfasst hier drei Dimensionen: Komplexität (wie schwierig ist die Arbeit?), Umfang (wie viel Arbeit steckt dahinter?) und Unsicherheit (was wissen wir noch nicht?).

Das Schlüsselwort ist relativ. Eine Story im Wert von 3 Punkten bedeutet nicht "3 Stunden Arbeit". Sie bedeutet, dass das Team davon ausgeht, dass sie etwa dreimal so viel Aufwand erfordert wie eine 1-Punkt-Story und etwa halb so viel wie eine 8-Punkte-Story. Die Zahl ist ein Vergleich, keine Messung.

Diese Unterscheidung ist wichtig. Menschen sind bekanntermaßen schlecht darin, absolute Dauern zu schätzen ("das dauert 4 Stunden"), aber ziemlich gut in relativen Vergleichen ("diese Aufgabe ist etwa doppelt so schwer wie jene"). Story Points nutzen genau diesen kognitiven Vorteil.

Key Facts: Story Points und Agile-Schätzung

• Teams, die relative Schätzung (Story Points oder Ähnliches) nutzen, berichten laut Scrum.org-Forschung zur Sprint-Vorhersagbarkeit von konsistenterer Sprint-Lieferung als Teams, die in Stunden schätzen.
• Der 17. State of Agile Report (digital.ai, 2023) ergab, dass 88 % der Agile-Praktiker Scrum oder eine Scrum-Hybridform nutzen, wodurch die Schätzung mit Story Points in der Branche nahezu universell ist.
• Laut der CHAOS-Report-Serie der Standish Group gehören schlechte Schätzungen und unklare Anforderungen durchgängig zu den drei häufigsten Ursachen für Projektüberschreitungen, was unterstreicht, warum eine strukturierte Schätzmethode wie Story Points wichtig ist.
• Eine Einordnung, die Teams beim Kalibrieren hilft: "Ein Story Point misst den Aufwand des Teams, nicht den Kalender. Dasselbe Feature kann für ein erfahrenes Team 5 Punkte kosten und für ein juniorlastiges Team 13, und beide Antworten sind in ihrem jeweiligen Kontext korrekt."

Story Points vs. Stunden

Teams, die neu im Agile-Umfeld sind, fragen oft, warum sie nicht einfach in Stunden schätzen können. Hier der ehrliche Vergleich:

Stunden wirken präzise, sind es aber nicht. Wenn ein Entwickler sagt "das sind vier Stunden", meint er eigentlich: "wenn nichts schiefgeht, wenn ich nicht unterbrochen werde, wenn ich die Codebase schon kenne und wenn sich die Anforderungen nicht ändern." Story Points erkennen Mehrdeutigkeit an, statt sie zu verstecken.

Dennoch haben Stunden weiterhin ihren Platz. Festpreisverträge, Compliance-Audits und die Abrechnung mit Kunden brauchen alle zeitbasierte Schätzungen. Der Trick liegt darin, zu wissen, welches Werkzeug zu welchem Kontext passt.

Warum Teams Story Points nutzen (Vorteile)

Schnellere Schätz-Sessions. Zu diskutieren, ob etwas 6 oder 8 Stunden dauert, ist mühsam. Zu diskutieren, ob es eine 5 oder eine 8 ist (auf der Fibonacci-Skala), geht deutlich schneller, weil der Abstand zwischen den Werten bewusst groß ist.

Gemeinsame Verantwortung für Schätzungen. Wenn das gesamte Team Arbeit gemeinsam bemisst, versteht jeder den Umfang. Entwickler erkennen Implementierungsdetails, die Product Owner übersehen haben. QA markiert Randfälle frühzeitig. Die Schätzung wird zu einer Art Vertrag, den das Team mit sich selbst schließt.

Velocity als Prognosewerkzeug. Sobald ein Team mehrere Sprints abgeschlossen hat, wird seine durchschnittliche Velocity (abgeschlossene Story Points pro Sprint) zu einem verlässlichen Prädiktor. Wenn Ihr Team im Schnitt 40 Punkte pro Sprint schafft, dauert ein Backlog von 200 Punkten etwa fünf Sprints. Das ist eine Roadmap.

Weniger Ankereffekte. Wenn ein erfahrener Ingenieur vor Beginn der Schätzung sagt "das ist ein Zwei-Tage-Job", passen sich alle anderen unbewusst an diese Zahl an. Story Points, insbesondere wenn sie gleichzeitig bei Planning Poker aufgedeckt werden, verhindern, dass eine einzelne Stimme dominiert.

Bessere Gespräche, nicht nur Zahlen. Wenn zwei Personen unterschiedliche Punktwerte wählen, bringt diese Uneinigkeit versteckte Komplexität ans Licht. Der wertvollste Teil der Schätzung ist nicht die Zahl, auf die man sich einigt, sondern das Gespräch, das dorthin führt.

Häufige Fehler und Grenzen

Punkte mit Stunden gleichsetzen. Das ist der häufigste Fehler. Sobald eine Führungskraft fragt "wie viele Stunden sind also 1 Punkt?", beginnt das ganze System zu bröckeln. Punkte sind keine Zeiteinheit.

Velocity zwischen Teams vergleichen. Team A schafft im Schnitt 50 Punkte pro Sprint, Team B 30. Das heißt nicht, dass Team A schneller ist. Unterschiedliche Teams kalibrieren ihre Skalen unterschiedlich. Teamübergreifende Velocity-Vergleiche sind wie der Vergleich von Preisen in verschiedenen Währungen, ohne den Wechselkurs zu kennen.

Schätzungen aus Selbstschutz aufblähen. Wenn Teams lernen, dass verpasste Schätzungen zu Schuldzuweisungen führen, polstern sie auf. Eine 3-Punkte-Story wird "vorsichtshalber" zur 5. Das bläst die Velocity auf und untergräbt die Prognosegenauigkeit langfristig. Kulturen ohne Angst vor Fehlern liefern bessere Schätzungen.

Sich an der Skala eines früheren Sprints orientieren. Teams verändern sich. Was früher eine 3-Punkte-Story war, ist heute vielleicht effektiv eine 5, weil die Codebase gewachsen ist. Regelmäßige Neukalibrierung hält die Skala ehrlich.

Punkte zur Messung individueller Produktivität nutzen. Story Points gehören dem Team. Zu verfolgen, wie viele Punkte jeder einzelne Entwickler "produziert" hat, macht aus einem Prognosewerkzeug eine Leistungskennzahl, was beides zerstört.

Zu früh zu detailliert schätzen. Stories, die für nächstes Quartal geplant sind, brauchen keine 3-Punkte-Präzision. Grobe T-Shirt-Größen (S/M/L/XL) reichen aus, bis eine Story ein oder zwei Sprints vor der Umsetzung steht.

So schätzen Sie mit Story Points (Schritt für Schritt)

Schritt 1: Einigen Sie sich auf Ihre Referenzstory

Wählen Sie vor Ihrer ersten Schätz-Session eine echte Story, die das gesamte Team versteht. Das wird Ihre Baseline. Weisen Sie ihr 3 Punkte zu (oder was sich nach mittlerem Aufwand anfühlt). Jede zukünftige Story wird relativ zu dieser bewertet.

Eine gute Baseline enthält alle drei Schätzdimensionen in moderatem Ausmaß: etwas Komplexität, eine angemessene Menge zu schreibenden Codes und etwas (aber nicht überwältigende) Unsicherheit.

Schritt 2: Nutzen Sie die Fibonacci-Folge

Die gängigste Story-Point-Skala ist eine modifizierte Fibonacci-Folge: 1, 2, 3, 5, 8, 13, 21. Manche Teams ergänzen 0 (trivial), 40 und 100 für Arbeit auf Epic-Ebene.

Warum Fibonacci? Weil die Abstände zwischen den Werten mit steigenden Zahlen wachsen. Eine 5-Punkte-Story und eine 8-Punkte-Story fühlen sich spürbar unterschiedlich an. Eine 5-Punkte- und eine 6-Punkte-Story wahrscheinlich nicht. Die Skala zwingt das Team, echte Unterschiede zu treffen, ohne eine Präzision vorzutäuschen, die nicht existiert.

Stories, die auf 13 oder höher geschätzt werden, sind starke Kandidaten für eine Aufteilung. Große Schätzungen signalisieren meist, dass der Umfang noch nicht gut verstanden ist.

Schritt 3: Führen Sie eine Planning-Poker-Session durch

Planning Poker ist die Standardtechnik für die gemeinsame Schätzung:

1. Der Product Owner liest eine User Story vor und beantwortet klärende Fragen.
2. Jedes Teammitglied wählt privat eine Punktkarte (oder eine Zahl in einem digitalen Tool).
3. Alle decken ihre Schätzung gleichzeitig auf.
4. Weichen die Schätzungen um mehr als einen Schritt voneinander ab (z. B. wählt eine Person 3, eine andere 13), erklären die Ausreißer ihre Überlegung.
5. Das Team diskutiert und schätzt erneut, bis eine Einigung erreicht ist.

Das gleichzeitige Aufdecken ist entscheidend. Es verhindert Ankereffekte und stellt sicher, dass jede Stimme gehört wird, bevor sich ein Konsens bildet.

Schritt 4: Kalibrieren Sie über die Velocity

Berechnen Sie nach Ihren ersten Sprints die Velocity Ihres Teams: die insgesamt in einem Sprint abgeschlossenen Story Points. Zählen Sie Stories, die aus einem vorherigen Sprint übernommen wurden, nicht als "erledigt".

Nach 4-6 Sprints haben Sie eine verlässliche Velocity-Spanne. Nutzen Sie das untere Ende dieser Spanne für konservative Prognosen, den Durchschnitt für die übliche Planung.

Die Velocity passt sich natürlich an, wenn die Fähigkeiten des Teams, die Vertrautheit mit der Codebase und die Schätzgewohnheiten reifen. Versuchen Sie nicht, sie durch geschönte Schätzungen künstlich aufzublähen.

Schritt 5: Kalibrieren Sie die Baseline regelmäßig neu

Überprüfen Sie mindestens einmal pro Quartal Ihre Referenzstory. Hat sich das Verständnis des Teams von "mittlerem Aufwand" verändert? Falls ja, passen Sie an. Das Ziel ist Konsistenz innerhalb des Teams über die Zeit, nicht Konsistenz mit einem externen Standard.

Beispiele für Story Points

So könnte ein beispielhaftes agiles Team eine Reihe von Backlog-Einträgen für ein B2B-SaaS-Produkt schätzen, samt Begründung und der resultierenden Velocity.

Schließt dieses Team die 1-, 2-, 3-, 5- und 8-Punkte-Stories in Sprint 1 ab, liegt seine Velocity bei 19 Punkten. Nach einigen Sprints pendelt sich die durchschnittliche Velocity angenommen bei 22 Punkten ein. Ein Backlog von 110 Story Points ergibt eine Prognose von 5 Sprints, also etwa 10 Wochen bei zweiwöchigen Sprints.

Die 13-Punkte-Story für das Zahlungsgateway ist eine Kandidatin für eine Aufteilung. "Zahlungsanbieter-Optionen recherchieren und Integrationsansatz dokumentieren" könnte eine 5 sein, "Integration umsetzen und testen" eine 8 oder 13. Aufteilen macht Fortschritt sichtbar und reduziert das Sprint-Risiko.

Best Practices

Tun:

• Stories als Team bemessen, nicht als Einzelpersonen
• Jede Story über 13 Punkten aufteilen, bevor sie in einen Sprint eingeplant wird
• Velocity über rollierende 4-6-Sprint-Fenster verfolgen, nicht über einzelne Sprints
• Die Baseline-Story während Schätz-Sessions griffbereit halten
• Entwicklern die Schätzungen überlassen; Product Ownern die Priorisierung überlassen
• User Stories als primäre Schätzeinheit nutzen, damit der Umfang im Nutzerwert verankert bleibt

Nicht tun:

• Punkte in offizieller Kommunikation in Stunden umrechnen
• Velocity zwischen Teams vergleichen oder als Einstellungs- oder Leistungssignal verwenden
• Eine einzelne Stimme die Schätzung dominieren lassen, bevor die Karten aufgedeckt sind
• Schätzungen mitten im Sprint wegen Scope Creep neu öffnen; stattdessen als neue Story protokollieren
• Die Schätzung "schneller" Stories überspringen; ein 10-minütiges Gespräch verhindert eine Zwei-Tage-Überraschung

Ein Hinweis zur Sprint-Planung: Story-Point-Schätzungen sind der wichtigste Input für die Entscheidung, wie viel in einen Sprint gezogen wird. Eine Überplanung um 20 % ist bei neuen Teams üblich. Sobald sich die Velocity stabilisiert, verbessert sich die Planungsgenauigkeit deutlich.

Häufig gestellte Fragen

Warum Fibonacci-Zahlen statt 1, 2, 3, 4, 5 verwenden?

Die Fibonacci-Folge hat wachsende Abstände zwischen den Werten (1, 2, 3, 5, 8, 13...), eine lineare Skala nicht. Wenn Sie eine 5-Punkte-Story gegen eine 6-Punkte-Story abwägen, geht es meist um Haarspalterei. Mit Fibonacci erzwingt der Sprung von 5 auf 8 ein echtes Gespräch: Hat diese Story genug zusätzliche Komplexität, um eine größere Zahl zu rechtfertigen? Diese Reibung führt zu besseren Entscheidungen.

Wie viele Stunden sind ein Story Point?

Gar keine feste Zahl. Story Points bilden Stunden bewusst nicht ab. Liegt die Velocity Ihres Teams bei 20 Punkten pro Zweiwochen-Sprint und Sie arbeiten 80 Team-Stunden pro Sprint, könnten Sie rechnerisch auf 4 Stunden pro Punkt kommen, aber diese Rechnung bricht sofort zusammen, sobald sich die Teamgröße ändert, die Komplexität variiert oder ein Sprint ungewöhnlich viele oder wenige Unterbrechungen hat. Nutzen Sie die Velocity für Zeitprognosen, nicht die Stunden-pro-Punkt-Rechnung.

Story Points vs. T-Shirt-Größen (S/M/L/XL)?

T-Shirt-Größen sind eine schnellere, weniger präzise relative Schätzmethode, die oft für die Planung auf Roadmap-Ebene genutzt wird. Sie eignen sich hervorragend für Features, die drei oder mehr Quartale entfernt liegen. Story Points sind besser für Arbeit auf Sprint-Ebene geeignet, weil sie die Velocity-Berechnung unterstützen. Viele Teams nutzen beides: T-Shirt-Größen für die Backlog-Verfeinerung auf Roadmap-Ebene, dann Umrechnung in Punkte, sobald ein Feature ein bis zwei Sprints vor der Umsetzung steht.

Funktionieren Story Points auch außerhalb der Softwareentwicklung?

Ja. Marketing-Teams, Content-Teams und Operations-Teams nutzen alle Story Points oder ähnliche relative Schätztechniken. Die Fibonacci-Skala und Planning Poker funktionieren für jede Arbeit, die Komplexität und Unsicherheit beinhaltet, nicht nur für Code. Die Kalibrierung dauert in Bereichen ohne etablierte Baseline nur länger.

Was passiert, wenn eine Story länger dauert als geschätzt?

Im Idealfall nichts. Schätzungen sind Prognosen, keine Zusagen. Wenn eine 3-Punkte-Story doppelt so lange dauert wie erwartet, ist die richtige Reaktion ein Gespräch im Team: War die Schätzung falsch, oder hat sich der Umfang geändert? Dann den Prozess anpassen, nicht die Person. Anhaltende Unterschätzung in einer Kategorie (etwa, alle API-Integrations-Stories dauern länger) ist ein Signal, die Skala anzupassen oder diese Stories konsequenter aufzuteilen.

Wie es weitergeht

Story Points sind eine Ebene eines umfassenderen agilen Schätz- und Planungssystems. Sobald Ihr Team eine stabile Velocity hat, kombinieren Sie die Story-Point-Schätzung mit der Sprint-Planung, um realistische Sprint-Ziele zu setzen, und mit Burndown-Charts, um den Fortschritt in Echtzeit zu verfolgen.

Wenn Ihr Team gerade erst mit Agile beginnt, geben das Agile Manifest und Was ist Agile-Methodik nützlichen Kontext dazu, warum relative Schätzung überhaupt entstanden ist. Für Teams, die bereits Sprints durchführen, sind Sprint-Retrospektiven der Mechanismus, um die Schätzgenauigkeit im Laufe der Zeit zu verbessern.

Weiterführende Artikel

• Was ist Scrum
• Planning Poker: So führen Sie Schätz-Sessions durch
• User Stories: So schreiben Sie sie gut
• Leitfaden zur Sprint-Planung
• Burndown-Chart: Lesen und Nutzen
• Scrum vs. Kanban