Agile Story Points: Ein praktischer Leitfaden zum Schätzen ohne Stunden
Story Points sind eine relative Einheit, mit der agile Teams Arbeit schätzen. Statt „diese Aufgabe dauert sechs Stunden” sagt das Team „diese Aufgabe ist eine 5 — ungefähr so groß wie das andere Ding aus dem letzten Sprint”. Das ist die ganze Idee. Alles andere — Fibonacci-Skalen, Velocity-Charts, Planning-Poker-Sessions — baut auf diesem einen Wechsel von absoluter Zeit zu relativer Größe auf.
Dieser Leitfaden erklärt, was Story Points messen, warum sie bewusst keine Stunden sind, welche Skalen Teams nutzen, wie eine Story-Pointing-Session konkret abläuft und wie die Zahlen in Jira landen. Am Ende gibt es ein Cheat Sheet, das du neben dein Backlog legen kannst.
Was Story Points wirklich messen
Ein Story Point bündelt drei Dinge in einer Zahl:
- Komplexität — wie viele bewegliche Teile die Arbeit hat und wie viel Denkarbeit nötig ist
- Unsicherheit — wie viel an der Arbeit unbekannt ist oder von Dingen außerhalb des Teams abhängt
- Aufwand — die schlichte Menge an Arbeit, unabhängig davon, wer sie macht
Die entscheidende Eigenschaft: Story Points sind relativ. Eine 4-Punkte-Story ist ungefähr doppelt so groß wie eine 2-Punkte-Story — für dein Team, auf eurer Codebasis, mit eurem Tooling. Außerhalb dieses Kontexts bedeutet die Zahl nichts, und das ist Absicht.
In der Praxis verankern Teams die Skala mit einer Referenz-Story: Nehmt ein kleines, gut verstandenes Stück Arbeit, an das sich alle erinnern — etwa „ein Feld zum Anmeldeformular hinzufügen” — und nennt es eine 2. Ab dann ist jede Schätzung ein Vergleich: größer oder kleiner als die Referenz, und ungefähr um wie viel?
Zwei Personen mit sehr unterschiedlicher Erfahrung können sich einig sein, dass Aufgabe A etwa doppelt so groß ist wie Aufgabe B — auch wenn beide völlig unterschiedlich lange dafür brauchen würden. Deshalb erzeugt relatives Schätzen meist weniger Streit als Zeitschätzungen: Die Vergleichsfrage lässt sich ehrlicher beantworten als „wie viele Stunden brauchst du?”.
Warum Story Points keine Stunden sind
Der häufigste Story-Points-Fehler ist die stille Rückumrechnung in Zeit. Sie taucht meist als Umrechnungstabelle auf, die jemand ins Wiki pinnt: 1 Punkt = 4 Stunden, 2 Punkte = 1 Tag, und so weiter.
Sobald diese Tabelle existiert, hast du keine Story Points mehr — du hast Stunden mit Extraschritten. Alle Probleme, die Story Points vermeiden sollten, kommen zurück: Leute ankern auf ihrer eigenen Geschwindigkeit statt auf der Größe der Arbeit, Schätzungen werden als Zusagen behandelt, und Diskussionen verschieben sich von „wie groß ist das?” zu „warum hat es länger gedauert, als die Tabelle sagt?”.
Die Verbindung zur Zeit existiert, aber sie läuft über die Velocity: Nach ein paar Sprints weißt du, dass dein Team etwa 25–30 Punkte pro Sprint schafft. Das ist deine Planungszahl. Sie übersetzt Punkte in Zeit — auf Team-Ebene, basierend auf gemessenen Daten. Nicht pro Aufgabe, und nicht nach einer ausgedachten Tabelle.
Fairerweise: Zeitbasiertes Schätzen ist nicht falsch. Für Teams mit Kundenabrechnung, Support-Arbeit oder harten externen Deadlines können Stunden die ehrlichere Einheit sein. Wir haben beide Ansätze in Zeit vs. Story Points verglichen, wenn du die vollständige Abwägung lesen willst. Story Points lohnen sich vor allem in iterativer Produktarbeit, wo relative Größenschätzung plus gemessene Velocity die Zeitschätzung pro Aufgabe schlägt.
Story-Point-Skalen: Fibonacci, T-Shirt-Größen, eigene Werte
Die meisten Teams nutzen eine modifizierte Fibonacci-Folge: 1, 2, 3, 5, 8, 13, 21. Die wachsenden Lücken sind der Punkt — über den Unterschied zwischen 1 und 2 kann ein Team sinnvoll diskutieren, der Unterschied zwischen 20 und 21 ist falsche Präzision. Größere Arbeit trägt mehr Unsicherheit, also wird die Skala gröber, je höher die Zahlen werden. Die vollständige Begründung steht in warum Planning Poker die Fibonacci-Reihe nutzt.
Zwei verbreitete Alternativen:
- T-Shirt-Größen (XS, S, M, L, XL) — gut für frühe Roadmap-Schätzungen, wo Zahlen eine Genauigkeit suggerieren würden, die niemand hat. Für die Sprint-Planung weniger nützlich, weil sich Buchstaben nicht zu einer Velocity addieren lassen.
- Eigene Werte — manche Teams deckeln ihre Skala bei 8 („alles Größere wird gesplittet”), andere ergänzen eine Kaffeetassen-Karte für „ich brauche eine Pause”. Die meisten Planning-Poker-Tools, unseres eingeschlossen, lassen dich eigene Kartenwerte definieren.
Welche Skala du wählst, ist weniger wichtig, als sie konsistent zu nutzen. Velocity funktioniert nur, wenn eine 5 in diesem Sprint dasselbe bedeutet wie eine 5 im letzten.
Wie eine Story-Pointing-Session abläuft
Story Pointing funktioniert am besten als strukturierte Gruppenübung, und das Standardformat ist Planning Poker. Der Ablauf:
- Story vorlesen. Product Owner oder Moderator liest die User Story vor und beantwortet Verständnisfragen. Noch keine Zahlen.
- Alle schätzen gleichzeitig. Jedes Teammitglied wählt verdeckt eine Karte. Das gleichzeitige Aufdecken ist der Kern-Mechanismus — es verhindert Ankern, also dass die erste laut ausgesprochene Zahl alle anderen mitzieht.
- Aufdecken und vergleichen. Wenn die Schätzungen übereinstimmen: Zahl notieren, weiter. Zehn Minuten darüber zu diskutieren, ob etwas eine 3 oder eine 5 ist, ist meist verschwendete Zeit.
- Ausreißer diskutieren. Wenn jemand 2 sagt und jemand anderes 13, ist diese Lücke Information. Meist weiß einer von beiden etwas, das der andere nicht weiß — eine versteckte Abhängigkeit, eine existierende Hilfsfunktion, eine regulatorische Anforderung. Erst die Ausreißer erklären lassen, dann neu abstimmen.
- Neu abstimmen, bis es nah genug ist. Zwei Runden sind typisch. Konvergiert eine Story nach drei Runden nicht, ist sie meist zu vage oder zu groß — splitten oder zurück ins Refinement.
Ein paar praktische Zahlen aus der Nutzung unseres Tools: Teams mit 3–15 Personen sind der typische Fall, mit 10–20 Stories pro Session und deutlich unter zwei Stunden Gesamtdauer. Darüber hinaus sinkt die Schätzqualität schneller als das Backlog.
Planning Poker ist eines von mehreren Schätzformaten — Affinity Estimation und andere skalieren besser für sehr große Backlogs — aber für Schätzungen auf Sprint-Ebene mit einem einzelnen Team ist es aus gutem Grund der Standard.
Story Points in Jira
Wenn dein Team in Jira arbeitet, leben Story Points in einem eigenen Feld, und Jiras Velocity- und Burndown-Reports aggregieren sie automatisch, sobald das Feld befüllt ist. Drei Dinge, die man wissen sollte:
- Das Feld muss eventuell aktiviert werden. Jira unterstützt ein „Story Points”-Feld auf Issues, aber je nach Template musst du es erst zu deinen Screens hinzufügen.
- Jira speichert Schätzungen; es erzeugt sie nicht. Es gibt keinen eingebauten Abstimmungs- oder Gleichzeitig-Aufdecken-Mechanismus — die Entscheidung, welche Zahl ins Feld kommt, passiert außerhalb von Jiras Kern-Funktionsumfang, entweder über ein kostenpflichtiges Marketplace-Plugin oder ein eigenständiges Tool im zweiten Browser-Tab. Beide Workflows haben wir ehrlich verglichen — inklusive der Fälle, in denen das Plugin die bessere Wahl ist — in Planning Poker für Jira ohne Plugin.
- Jira akzeptiert jede Zahl; dein Team sollte das nicht. Das Feld nimmt beliebige Dezimalzahlen. Bleibt trotzdem bei eurer vereinbarten Skala — ein Backlog mit 3,5ern und 6ern bedeutet, dass jemand im Kopf in Zeit umrechnet.
Kurzfassung: Story Points in Jira sind ein Output. Die Schätzung selbst — die Diskussion, das Aufdecken, das Neu-Abstimmen — ist das, worum es in diesem Artikel geht, und sie passiert im Gespräch, nicht im Feld.
Story-Points-Cheat-Sheet
Eine Referenztabelle für die modifizierte Fibonacci-Skala. Die Beschreibungen sind ein Startpunkt — die Referenz-Stories deines Teams schärfen sie mit der Zeit.
| Punkte | Grobe Bedeutung | Typische Aktion |
|---|---|---|
| 1 | Trivial. Gut verstanden, winzige Änderung. | Einfach machen. |
| 2 | Klein. Bekanntes Terrain, keine Überraschungen erwartet. | Gute Referenz-Story-Größe. |
| 3 | Mittel. Etwas Denkarbeit, kleinere Unbekannte. | Normale Sprint-Kost. |
| 5 | Groß. Mehrere bewegliche Teile oder eine echte Unbekannte. | Okay, aber prüfen, ob sie in einen Sprint passt. |
| 8 | Sehr groß. Mehrere Unbekannte, berührt mehrere Bereiche. | Splitten in Erwägung ziehen. |
| 13 | Riesig. Erhebliche Unsicherheit. | Splitten, außer es gibt einen harten Grund dagegen. |
| 21 | Zu groß für eine ehrliche Schätzung. | Immer splitten. Das ist ein Epic im Story-Kostüm. |
Häufige Fehler (und ehrliche Grenzen)
Die Fehler, die wir am häufigsten sehen:
- Punkte pro Aufgabe in Stunden umrechnen. Oben behandelt — es löscht still den Nutzen des ganzen Systems.
- Mitteln statt diskutieren. Wenn die Stimmen 2, 3, 5 und 13 sind, ist die Antwort nicht 5,75. Die 13 hat einen Grund; findet ihn.
- Velocity zwischen Teams vergleichen. Die 30 Punkte von Team A und die 30 Punkte von Team B haben nichts miteinander zu tun. Team-übergreifender Velocity-Vergleich bestraft ehrliche Schätzer und belohnt Inflation.
- Punkte als Leistungskennzahl nutzen. In dem Moment, in dem „gelieferte Punkte” in Leistungsbeurteilungen auftauchen, blähen sich Schätzungen auf und die Daten werden wertlos. Velocity ist ein Planungs-Input, kein Produktivitätsmaß.
Und die ehrlichen Grenzen: Story Points reparieren keine unklaren Anforderungen, kein instabiles Team und keinen Product Owner, der mitten im Sprint die Prioritäten umsortiert — sie machen diese Probleme nur schneller sichtbar, was unbequem, aber nützlich ist. Für sehr kleine Teams (zwei oder drei Personen), die ohnehin den vollen Kontext teilen, kann formales Pointing mehr Zeremonie sein, als es wert ist; ein kurzes „klein, mittel oder gruselig?” tut manchmal denselben Dienst. Und die Velocity-Daten der ersten Sprints werden verrauscht sein — das ist normal und kein Zeichen, dass ihr etwas falsch macht.
FAQ
Was sind Story Points in der agilen Entwicklung? Eine relative Einheit zum Schätzen von Arbeit. Statt Zeit zu schätzen, bewertet das Team die Größe jeder Story — Komplexität, Unsicherheit und Aufwand kombiniert — im Vergleich zu bereits erledigter Arbeit. Die Zahlen sind team-spezifisch und nur innerhalb dieses Teams aussagekräftig.
Wie viele Stunden ist ein Story Point? Es gibt absichtlich keine feste Umrechnung. Die Verbindung zwischen Punkten und Zeit entsteht auf Team-Ebene über die Velocity — die Punkte, die dein Team tatsächlich pro Sprint abschließt, gemessen über mehrere Sprints. Jede Umrechnungstabelle pro Aufgabe macht aus Story Points wieder Stunden und entfernt ihren Nutzen.
Welche Skala sollten wir für Story Points nutzen? Die modifizierte Fibonacci-Folge (1, 2, 3, 5, 8, 13, 21) ist die häufigste Wahl, weil die wachsenden Lücken zur wachsenden Unsicherheit größerer Arbeit passen. T-Shirt-Größen funktionieren für grobe Roadmap-Schätzungen. Konsistenz ist wichtiger als die konkrete Skala.
Funktionieren Story Points außerhalb von Software-Teams? Ja — der Mechanismus ist generisch. Jedes Team, das Arbeit mit eingebauter Unsicherheit schätzt (Marketing-Kampagnen, Content-Produktion, Hardware-Prototyping), kann relativ schätzen und eine Velocity verfolgen. Der Referenz-Story-Trick funktioniert genauso.
Wenn du Story Pointing mit deinem Team ausprobieren willst: Öffne einen kostenlosen Planning-Poker-Raum — keine Anmeldung, Link teilen, abstimmen. Die kostenlose Version zeigt Werbung; Premium (40 USD/Jahr für das ganze Team) entfernt sie. Eine Sprint-Planung reicht, um zu sehen, ob relatives Schätzen zu deinem Team passt.