Story Points in der Entwicklung — was sie sind, Bewertungsskalen und Anwendung
Story Points sind relative Einheiten zur Messung der Aufgabenkomplexität in agilen Entwicklungsmethoden. Im Gegensatz zu Stunden berücksichtigen Story Points nicht nur die Zeit, sondern auch die Komplexität, Risiken und Unsicherheit einer Aufgabe. Laut Scrum.org, 2023, verpassen Teams, die relative Schätzung in Story Points verwenden, Sprint-Termine um 25% seltener als Teams, die in Stunden schätzen.
Wichtige Erkenntnisse
- Story Points — relative Einheiten der Aufgabenkomplexität, nicht an Zeit gebunden.
- Hauptskalen — Fibonacci (1, 2, 3, 5, 8, 13, 21) und linear (1, 2, 3, 4, 5).
- Velocity — die Anzahl der Story Points, die ein Team pro Sprint abschließt, wird für Prognosen verwendet.
- Hauptvorteil — Story Points hängen nicht vom einzelnen Entwickler ab und spiegeln die Komplexität für das Team wider.
- Wichtige Regel — eine Referenzaufgabe definiert den Maßstab: Das Team vereinbart, was 1 Story Point bedeutet.
Was sind Story Points?
Story Points sind eine Metrik der Aufgabenkomplexität, die in Scrum und anderen agilen Methoden verwendet wird. Das Team bewertet jede Aufgabe nicht in Stunden, sondern in relativen Einheiten: „diese Aufgabe ist doppelt so komplex wie die Referenz.“ Dieser Ansatz gleicht den Geschwindigkeitsunterschied zwischen verschiedenen Entwicklern aus und konzentriert sich auf die Komplexität.
Ursprung des Begriffs
Das Konzept der Story Points entstand Anfang der 2000er Jahre mit der Popularisierung von Scrum. Einer der ersten, der die Methode beschrieb, war Ron Jeffries im Rahmen von Extreme Programming (XP). Die Idee war, sich von der Schätzung in „Personenstunden,“ die immer ungenau ist, hin zur relativen Komplexität zu bewegen, die das Team gemeinsam bestimmt. Heute sind Story Points der Industriestandard für agile Teams.
Faktoren, die in Story Points berücksichtigt werden
Bei der Schätzung in Story Points berücksichtigt das Team drei Faktoren: Arbeitsvolumen (Menge an Code, Bildschirmen, Logik), Komplexität (technische Herausforderungen, neue Technologien) und Unsicherheit (unklare Anforderungen, Risiken). Ein Story Point kann „eine einfache Aufgabe ohne Risiken“ bedeuten, während 8 „eine komplexe Aufgabe mit hoher Unsicherheit“ bedeuten kann.
Story-Point-Skalen: Wie man wählt
Die Wahl der Story-Point-Skala beeinflusst die Schätzgenauigkeit und die Planungsfreundlichkeit. Die beliebteste Skala ist die Fibonacci-Folge, aber es gibt Alternativen.
| Skala | Werte | Vorteile | Nachteile |
|---|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | Natürliche Streuungszunahme bei großen Aufgaben | Schwierig für neue Teams |
| Linear | 1, 2, 3, 4, 5 | Einfach und verständlich | Keine Streuung bei großen Aufgaben |
| Potenz | 1, 2, 4, 8, 16, 32 | Maximale Streuung bei großen Aufgaben | Große Aufgaben sind schwer zu unterscheiden |
| T-Shirt | S, M, L, XL | Schnelle grobe Schätzung | Ungenau, erfordert Umrechnung |
Warum Fibonacci? Die Psychologie der Skala
Die Fibonacci-Folge wurde nicht zufällig gewählt. Der Unterschied zwischen 1 und 2 ist minimal (50%), während er zwischen 13 und 21 signifikant ist (62%). Dies spiegelt die Realität wider: Kleine Aufgaben werden genauer geschätzt, große Aufgaben mit größerer Streuung. Wenn eine Aufgabe auf 21 Story Points geschätzt wird, versteht das Team: „wir wissen nicht, wie lange es dauern wird, aber es ist definitiv mehr als 13.“ Die Fibonacci-Skala verhindert falsche Genauigkeit.
Die Referenzaufgabe — Grundlage der Skala
Damit die Skala funktioniert, einigt sich das Team auf eine Referenz: „Aufgabe X ist 1 Story Point.“ Üblicherweise wird eine einfache, gut bekannte Aufgabe als Referenz gewählt: „Ein Textfeld zu einem Bildschirm hinzufügen“ oder „Einen Tippfehler-Bug beheben.“ Alle anderen Aufgaben werden relativ zur Referenz geschätzt. Ohne Referenz verlieren Story Points ihre Bedeutung — jeder versteht die Einheit anders.
Team-Velocity und Prognose
Velocity ist die durchschnittliche Anzahl von Story Points, die ein Team pro Sprint abschließt. Dies ist eine Schlüsselmetrik für die Prognose von Projektzeitplänen.
Wie Velocity berechnet wird
Velocity wird auf der Grundlage abgeschlossener Aufgaben berechnet: Die Story Points aller Aufgaben, die das Team fertigstellen konnte (Definition of Done erfüllt), werden summiert. Nicht abgeschlossene Aufgaben werden nicht gezählt. Zur Genauigkeit wird der Durchschnitt der letzten 3–5 Sprints genommen. Wenn ein Team beispielsweise in den letzten 4 Sprints 20, 22, 18 und 24 Story Points abgeschlossen hat, beträgt die Velocity 21 SP.
Prognose durch Velocity
Wenn man die Velocity und das gesamte Backlog-Volumen in Story Points kennt, kann man die Anzahl der Sprints bis zur Veröffentlichung prognostizieren. Wenn das Backlog beispielsweise 210 Story Points umfasst und die Velocity 21 beträgt, werden 10 Sprints benötigt. Dies ist eine grobe Prognose, die mit fortschreitender Arbeit verfeinert wird. Wichtig: Velocity ist ein Durchschnitt, keine Verpflichtung. Planen Sie auf der Grundlage der unteren Grenze (18 SP), nicht des Durchschnitts.
Wie man die Velocity erhöht
Velocity kann nicht per Dekret erhöht werden — sie ist ein Symptom für die Gesundheit der Prozesse. Nachhaltiges Velocity-Wachstum wird erreicht durch: Reduzierung technischer Schulden, Verbesserung der Code-Review-Prozesse, Reduzierung von Kontextwechseln, Automatisierung von Tests und CI/CD. Wichtig: Die Velocity verschiedener Teams kann nicht verglichen werden — jedes Team definiert Story Points auf seine eigene Weise.
Story Points vs. Stunden: Was und wann verwenden
Story Points und Stunden haben unterschiedliche Zwecke, und die Wahl zwischen ihnen hängt vom Kontext ab. Erfahrene Teams verwenden beide Ansätze für verschiedene Aufgaben.
Wann Story Points besser funktionieren
Story Points sind für die Sprintplanung unverzichtbar: Sie hängen nicht davon ab, wer die Aufgabe erledigt. Ein Junior kann 2 SP pro Tag erledigen, ein Senior 4 SP, aber die Aufgabenschätzung bleibt für beide bei 2 SP. Story Points ermöglichen es, die Teamproduktivität zu verfolgen, ohne Entwickler zu vergleichen. Dies reduziert politischen Druck und verbessert die Teamatmosphäre.
Wann Stunden notwendig sind
Stunden werden für externe Verpflichtungen benötigt: Verträge, Budgets, Kundenberichte. Ein Kunde möchte nicht „8 Story Points“, sondern „3 Wochen“ wissen. Zur Umrechnung von Story Points in Stunden verwenden Sie die historische Umrechnungsrate: Das Team weiß, dass 1 SP ungefähr 4 Arbeitsstunden entspricht. Die Umrechnung sollte transparent und datenbasiert sein, nicht auf Vermutungen beruhen.
Kombinierter Ansatz
Viele Teams verwenden einen kombinierten Ansatz: Aufgaben werden für die Sprintplanung in Story Points geschätzt, und dann konvertiert der Manager sie für externe Berichte in Stunden/Tage. Es ist wichtig, die beiden Systeme nicht in einem Prozess zu vermischen: Entweder Sie schätzen in Story Points und leiten die Zeit aus der Velocity ab, oder Sie schätzen direkt in Stunden.
Häufige Fehler bei der Arbeit mit Story Points
Die Einführung von Story Points wird oft von Fehlern begleitet, die die Vorteile der relativen Schätzung zunichtemachen. Hier sind die häufigsten.
Story Points an Zeit binden
Der häufigste Fehler — das Team vereinbart: „1 SP = 4 Stunden.“ In diesem Fall verlieren Story Points ihre Bedeutung und werden zu Stunden mit einem anderen Namen. Story Points sollten relativ sein, nicht an die Zeit gebunden. Wenn Aufgabe A doppelt so komplex ist wie Aufgabe B, erhält sie 2 SP, unabhängig davon, wie viele Stunden sie dauert.
Post-factum-Schätzung
Wenn eine Aufgabe nach ihrer Erledigung geschätzt wird — ist das keine Schätzung, sondern Dokumentation. Story Points sollten vor Arbeitsbeginn, im Moment der größten Unsicherheit, vergeben werden. Die Post-factum-Schätzung verzerrt die Velocity und bringt keinen Nutzen für die Planung. Darüber hinaus erzeugt sie ein falsches Gefühl von Genauigkeit.
Velocity verschiedener Teams vergleichen
Der Vergleich der Velocity von Team A und Team B ist eine sinnlose Übung. Jedes Team definiert Referenz und Skala anders. Für ein Team ist 1 SP eine einfache einstündige Aufgabe, für ein anderes eine eintägige Aufgabe. Sie können nur die Velocity desselben Teams im Zeitverlauf vergleichen: ob sie steigt oder fällt.
Inkonsistente Skala
Wenn verschiedene Aufgaben mit derselben Komplexität unterschiedliche Story Points erhalten und komplexere Aufgaben weniger, bricht die Skala zusammen. Das Team sollte die Skala regelmäßig kalibrieren: alle 3–6 Sprints retrospektiv überprüfen, wie gut die Schätzungen mit der tatsächlichen Komplexität übereinstimmten. Dies verbessert die Konsistenz der Schätzungen.
Häufig gestellte Fragen
Wie viele Stunden hat ein Story Point?
Story Points haben kein festes Äquivalent in Stunden. Es ist eine relative Einheit: 1 SP = Komplexität der Referenzaufgabe. Zur Umrechnung in Stunden verwenden Sie die historische Umrechnungsrate Ihres Teams: Teilen Sie die durchschnittliche Anzahl der pro Sprint gearbeiteten Stunden durch die Velocity. Normalerweise entspricht 1 SP = 4–8 Stunden, aber dies variiert von Team zu Team.
Können Story Points in Kanban verwendet werden?
Ja, Story Points können in Kanban verwendet werden, jedoch mit Einschränkungen. Kanban hat keine festen Sprints, daher wird die Velocity stattdessen pro Woche oder Monat berechnet. Kanban-Teams verwenden oft die Zykluszeit anstelle von Story Points — die Zeit, die eine Aufgabe von Anfang bis Ende benötigt. Die Wahl hängt von den Besonderheiten des Teams ab.
Was tun, wenn sich das Team nicht auf eine Schätzung einigen kann?
Wenn Schätzungen auseinandergehen (einer gibt 3 SP, ein anderer 13), ist das ein Zeichen dafür, dass die Aufgabe schlecht verstanden wird. Zerlegen Sie die Aufgabe in kleinere Teile. Besprechen Sie die Risiken und Unsicherheiten, die verschiedene Entwickler sehen. Wenn die Aufgabe groß ist, schätzen Sie sie als Spike (Recherche für 2–4 Tage) anstelle von Story Points.
Wie hört man auf, in Stunden zu schätzen, und wechselt zu Story Points?
Der Übergang dauert 3–6 Sprints. Beginnen Sie mit der Auswahl einer Skala (Fibonacci ist die sicherste Wahl) und der Definition einer Referenzaufgabe. Führen Sie 2–3 Planning-Poker-Sitzungen durch. Berechnen Sie die Velocity nach jedem Sprint. Konvertieren Sie Story Points nicht in Stunden — lassen Sie das Team sich an das neue System gewöhnen. Nach 3 Sprints werden Sie sehen, wie sehr sich die Planung verbessert hat.
Ändert sich die Story-Point-Schätzung einer Aufgabe nach ihrer Erledigung?
Nein, die Schätzung ändert sich nicht. Story Points sind eine vorläufige Komplexitätsschätzung, die vor Arbeitsbeginn erstellt wird. Nach Abschluss der Aufgabe bleibt die Schätzung gleich, auch wenn der tatsächliche Aufwand abgewichen ist. Eine nachträgliche Änderung der Schätzung verzerrt die Statistik und macht den Zweck der Prognose zunichte. Analysieren Sie Abweichungen in den Retrospektiven, ändern Sie aber keine Schätzungen im Nachhinein.
Zusammenfassung
- Story Points — relative Einheiten der Komplexität, nicht an Zeit gebunden, die Grundlage agiler Schätzung.
- Hauptskalen — Fibonacci (empfohlen), linear, Potenz, T-Shirt-Größen.
- Velocity — Anzahl der Story Points pro Sprint; Schlüsselmetrik für die Terminprognose.
- Story Points vs. Stunden — Story Points für die Sprintplanung, Stunden für externe Verpflichtungen.
- Häufige Fehler — Bindung an Zeit, Post-factum-Schätzung, Teamvergleiche, inkonsistente Skala.
- Referenzaufgabe — Grundlage der Skala; ohne sie verlieren Story Points ihre Bedeutung.
- Hauptvorteil — Story Points hängen nicht von der Einzelperson ab und ermöglichen die Fokussierung auf die Teamproduktivität.
Wir entwickeln eine mobile Applikation schlüsselfertig
IT Sectr entwickelt seit 2017 iOS- und Android-Apps für Startups und Unternehmen. Wir beraten Sie und schlagen die beste Lösung vor.
Lesen Sie auch