Was sind Story Points?
Story Points sind eine Maßeinheit in der agilen Softwareentwicklung, um den Gesamtaufwand für die vollständige Implementierung eines Backlog-Eintrags auszudrücken. Sie kodieren Komplexität, Arbeitsvolumen und Risiko — nicht Zeit.
Warum agile Teams Story Points statt Stunden verwenden
Stundenbasierte Schätzung erscheint präzise, scheitert aber konsequent in der Praxis. Sie verankert das Team an individueller Produktivität und schafft falsche Verantwortlichkeit.
Story Points formulieren die Frage um von "Wie lange wird das dauern?" zu "Wie komplex ist das im Vergleich zu etwas, das wir schon gemacht haben?"
Der Hauptunterschied
- Stunden schätzen Dauer basierend auf der Geschwindigkeit einer Person.
- Story Points schätzen Aufwand als Team-Level-Eigenschaft. Eine Story ist eine 8, unabhängig davon, welches Teammitglied daran arbeitet.
- Diese Abstraktion wirkt anfangs kontraintuitiv. Nach 3–4 Sprints finden die meisten Teams ihre Sprint-zu-Sprint-Velocity vorhersagbarer.
Was Story Points tatsächlich messen
Eine gut kalibrierte Story-Point-Schätzung erfasst drei Dimensionen der Arbeit:
- Komplexität: wie viele bewegliche Teile hat die Lösung?
- Volumen: wie viel Arbeit gibt es? Eine Story, die Änderungen an acht Dateien erfordert, ist größer als eine, die zwei ändert.
- Unsicherheit: wie gut versteht das Team die Lösung?
Häufige Story-Point-Skalen
Die Fibonacci-Sequenz (1, 2, 3, 5, 8, 13, 21) ist die am weitesten verbreitete Skala.
Manche Teams verwenden ein modifiziertes Fibonacci (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100), um sowohl winzige Aufgaben als auch große Epics zu berücksichtigen.
- 1, 2, 3, 5, 8, 13, 21 — Standard-Fibonacci. Am besten für Teams, die Sprint-Level-Schätzungen durchführen.
- 1, 2, 4, 8, 16, 32 — Zweierpotenzen. Bevorzugt von ingenieurslastigen Teams.
- XS, S, M, L, XL — T-Shirt-Größen. Am besten für frühe Entdeckung und Roadmap-Planung.
Wie man mit Story-Point-Schätzung beginnt
Mit Story Points zu beginnen ist einfacher als die meisten Teams erwarten. Der Schlüssel ist die Einrichtung von Anker-Stories.
Schritt 1: Eine Referenz-Story wählen
Eine kürzlich abgeschlossene Story finden, mit der das Team einig ist, dass sie eine klare, gut verstandene, mittlere Arbeitsaufgabe war. 3 oder 5 Punkte zuweisen.
Schritt 2: Relativ zur Referenz schätzen
Für jede neue Story fragt das Team: "Ist das größer oder kleiner als unsere 3-Punkte-Referenz? Um wie viel?" Gleichzeitig mit Planning Poker abstimmen.
Schritt 3: Velocity über 3–4 Sprints verfolgen
Nach einigen Sprints die gleitende Durchschnitts-Velocity berechnen. Diese als Kapazitäts-Input für Sprint Planning nutzen.
Story-Point-Schätzung mit deinem Team ausprobieren mit kostenlosem Online-Planning-Poker — keine Registrierung erforderlich.
Story Points FAQ
Sind Story Points dasselbe wie Ideal Days?
Nein. Ideal Days schätzen, wie lange eine Story dauern würde, wenn ein Entwickler ungestört daran arbeitet. Story Points sind teambasierte relative Maße.
Müssen Story Points sich zu etwas summieren?
Innerhalb eines Sprints sollten die Gesamtpunkte die Kapazität des Teams nicht überschreiten.
Warum ändert sich unsere Velocity ständig?
Velocity ändert sich, wenn sich die Teamzusammensetzung ändert, die Art der Stories ändert oder die Definition eines Punktes driftet.
Können verschiedene Teams ihre Story Points vergleichen?
Nein. Story Points sind innerhalb eines Teams bedeutungsvoll, nicht zwischen Teams.
Sollen Schätzungen Testing und Code Review einschließen?
Ja. Ein Story Point sollte den gesamten Aufwand repräsentieren, um eine Story bis zu Done zu bringen.
Schätze dein erstes Backlog mit kostenlosem Online-Planning-Poker