Story-Point-Schätzung: Der vollständige Agile-Leitfaden

Was sind Story Points?

Story Points sind eine relative Schätzmethode, die von Agile- und Scrum-Teams verwendet wird. Statt genaue Stunden vorherzusagen, vergleichen Teams ein Backlog-Element mit einem anderen und einigen sich auf eine Größe, die Aufwand, Komplexität und Risiko widerspiegelt.

Dies hilft Teams, sprint-übergreifend konsistenter zu planen, da die Schätzung auf relativer Größe basiert, nicht auf der Zeitschätzung einer einzelnen Person.

Warum ein Story-Point-Schätzwerkzeug verwenden?

• Schnellere Ausrichtung: Alle stimmen im gleichen Flow ab.
• Bessere Diskussion: Große Unterschiede enthüllen Annahmen und versteckte Arbeit.
• Vorhersehbarere Planung: Velocity wird im Laufe der Zeit nützlicher.
• Einfach für Remote-Teams: Ein gemeinsamer Link hält die gesamte Session zusammen.

Wie man Story Points gut schätzt

1. Wählen Sie ein klares Backlog-Element mit Akzeptanzkriterien.
2. Vergleichen Sie es mit einer oder zwei Referenz-Storys, die Ihr Team bereits versteht.
3. Stimmen Sie privat mit einer Skala wie 1, 2, 3, 5, 8, 13 und 21 ab.
4. Enthüllen Sie Stimmen gemeinsam und diskutieren Sie zuerst die höchsten und niedrigsten Schätzungen.
5. Stimmen Sie bei Bedarf erneut ab, bis das Team eine stabile Schätzung erreicht.

Sie können dies live mit ScrumVotes kostenlosem Schätzwerkzeug während Refinement oder Scrum-Planung tun.

Die Fibonacci-Folge und Story-Point-Skalen

Story Points funktionieren am besten mit einer nicht-linearen Skala, und die Fibonacci-Folge (1, 2, 3, 5, 8, 13, 21) ist die am weitesten verbreitete.

Die sich weitenden Lücken zwischen Fibonacci-Zahlen entsprechen der wachsenden Unsicherheit bei größeren Storys. Eine 1-Punkte-Story ist gut verstanden; eine 21-Punkte-Story hat so viele Unbekannte, dass die genaue Zahl kaum eine Rolle spielt.

Warum eine nicht-lineare Skala besser ist als eine lineare

• Reduziert falsche Präzision: Niemand kann zuverlässig zwischen einer 6-Punkte- und einer 7-Punkte-Story unterscheiden, aber jeder kann zwischen einer 5 und einer 8 unterscheiden.
• Treibt Story-Aufteilung: Wenn eine Story bei 13 oder 21 Punkten landet, signalisiert die Skala selbst, dass die Story wahrscheinlich zu groß für einen Sprint ist.
• Verbessert Velocity-Stabilität: Teams, die Fibonacci-basierte Skalen verwenden, produzieren tendenziell konsistentere Sprint-zu-Sprint-Velocity.

Story Points vs. Stunden: Warum relative Größenbestimmung gewinnt

Stundenbasierte Schätzung fühlt sich intuitiv an, aber erbringt in der Praxis konsistent schlechtere Ergebnisse.

Die Probleme mit stundenbasierter Schätzung

• Individuelle Varianz: Eine Aufgabe, die ein Senior-Entwickler in 2 Stunden erledigt, kann einem Junior-Entwickler 6 Stunden kosten.
• Optimismus-Bias: Menschen unterschätzen systematisch Zeit. Studien zeigen, dass Stundenbasierte Schätzungen typischerweise 30–50% optimistisch sind.
• Keine Berücksichtigung unbekannter Unbekannter: Stunden schätzen die Arbeit, die Sie kennen. Sie können die API nicht berücksichtigen, die sich als schlecht dokumentiert herausstellt.

Warum Story Points bessere Prognosen liefern

• Velocity stabilisiert sich: Sobald ein Team 3–4 Sprints Story-Point-Daten hat, wird ihre Velocity ein zuverlässiger Planungsinput.
• Relative Größenbestimmung ist schneller: Es ist schneller zu entscheiden "das ist eine 5, wie das Login-Formular, das wir letzten Monat erstellt haben".
• Trennt Aufwand von Elapsed-Zeit: Eine komplexe 8-Punkte-Story kann einen Tag intensiver Fokus-Arbeit oder fünf Tage unterbrochener Arbeit dauern.

Der Wechsel von Stunden zu Story Points dauert typischerweise 2–3 Sprints, bis ein Team ihn verinnerlicht.

Story Points sprintübergreifend kalibrieren

Das größte Risiko bei Story Points ist Skalendrift — die Definition des Teams von "einer 5" ändert sich im Laufe der Zeit, was Velocity-Zahlen inkomparabel macht.

Referenz-Storys verwenden, um die Skala zu verankern

Wählen Sie zwei oder drei abgeschlossene Storys, die das Team einstimmig als 1, 3 und 8 Punkte ansieht. Halten Sie diese als permanente Anker.

Referenz-Storys funktionieren am besten, wenn sie typisch sind, nicht außergewöhnlich.

Wann die Story-Point-Skala rekalibriert werden soll

Rekalibrieren wenn: signifikante Änderungen in der Teamzusammensetzung, eine große Technologieumstellung oder wenn das Team bemerkt, dass die Velocity konsistent steigt oder fällt.

Eine Rekalibrierungs-Session ist kein Eingeständnis, dass frühere Schätzungen falsch waren.

Bereit, die Schätzungen Ihres Teams zu kalibrieren? Führen Sie eine kostenlose Planning-Poker-Session durch und verwenden Sie Referenz-Storys als Ihre erste Abstimmung.