Story Points schätzen: Planning Poker und Velocity erklärt
Kurz gesagt
Story Points schätzt du relativ, nicht in Stunden: Das Team wählt eine kleine, gut verstandene Referenz-Story als 2 oder 3 Punkte und vergleicht neue Stories damit. Beim Planning Poker legen alle verdeckt eine Fibonacci-Karte, große Abweichungen werden besprochen. Aus der Velocity vergangener Sprints ergibt sich dann eine Prognose als Spanne.
Ron Jeffries, einer der Begründer von Extreme Programming, hat Story Points vermutlich miterfunden. Er bedauert es inzwischen. In einem Text von 2019 schreibt er, er habe die Umbenennung von „idealen Tagen“ in „Punkte“ womöglich selbst vorgeschlagen, und fügt hinzu: Falls ja, tue es ihm jetzt leid.
Die Geschichte erklärt viel. In Jeffries’ XP-Team wurde zunächst in idealen Tagen geschätzt und mit einem Lastfaktor von etwa drei auf echte Tage hochgerechnet. Weil Stakeholder nicht verstanden, warum ein „Tag“ drei Tage dauerte, wurde aus dem idealen Tag ein Punkt. Die Einheit sollte Verwirrung vermeiden. Heute stiftet sie oft neue.
Trotzdem funktionieren Story Points gut, wenn man sie richtig einsetzt. Und richtig heißt vor allem: relativ.
Warum relativ besser schätzt als absolut
Menschen können schlecht sagen, wie lange etwas dauert. Sie können aber recht zuverlässig sagen, ob etwas doppelt so groß ist wie etwas anderes. Story Points nutzen genau das. Das Team vergleicht jede neue Story mit Stories, die es schon kennt.
Ein Punktwert fasst dabei drei Dinge zusammen: die Menge an Arbeit, die Komplexität und das Risiko. Eine Story mit wenig Code, aber unbekannter Schnittstelle kann deshalb mehr Punkte bekommen als eine mit viel Routinearbeit.
Schritt 1: Referenz-Stories festlegen
Ohne gemeinsamen Maßstab ist jede Schätzung beliebig. Such dir zwei oder drei abgeschlossene Stories, die das ganze Team kennt:
| Referenz | Punkte | Warum |
|---|---|---|
| Pflichtfeld „Telefonnummer“ im Profil ergänzen, inkl. Validierung | 2 | klein, bekannt, kaum Risiko |
| Passwort-zurücksetzen-Ablauf mit E-Mail-Link | 5 | mehrere Teile, bekannte Technik |
| CSV-Import von Kundendaten mit Fehlerbericht | 13 | viele Sonderfälle, Datenqualität unklar |
Diese Tabelle hängt bei jeder Schätzrunde sichtbar. Neue Stories werden immer gegen sie gehalten: kleiner als der Passwort-Ablauf? Größer als das Pflichtfeld?
Schritt 2: Planning Poker
Planning Poker wurde 2002 von James Grenning beschrieben und später durch Mike Cohn bekannt. Der Ablauf ist einfach und hat einen klugen Kern: Alle legen gleichzeitig verdeckt eine Karte. Das verhindert, dass sich alle an der ersten genannten Zahl orientieren.
- Story vorstellenProduct Owner liest Story und Akzeptanzkriterien vor, beantwortet Fragen.
- Verdeckt wählenJeder wählt eine Karte, typische Werte: 1, 2, 3, 5, 8, 13, 20, 40, 100.
- Gleichzeitig aufdeckenAlle Karten werden auf ein Zeichen umgedreht.
- Ausreißer erklärenHöchster und niedrigster Wert begründen ihre Sicht. Oft weiß einer etwas, das die anderen übersehen.
- Neu schätzenZweite Runde. Meist liegt die Gruppe jetzt eng beieinander.
- FesthaltenWert notieren. Ohne Einigung nach drei Runden: Story ist zu unklar und geht zurück.
Warum Fibonacci-ähnliche Zahlen? Weil die Lücken mit der Größe wachsen. Zwischen 2 und 3 lohnt sich die Unterscheidung. Zwischen 20 und 21 nicht. Die Karten zwingen das Team, bei großen Stories grob zu bleiben, was der tatsächlichen Unsicherheit entspricht. Manche Decks enthalten zusätzlich ein Fragezeichen und eine Kaffeetasse für „Pause, bitte“.
Gute Stories sind die Voraussetzung. Fehlen Akzeptanzkriterien, schätzt jeder etwas anderes. Wie man sie schreibt, steht unter User Stories schreiben.
Schritt 3: Velocity messen und daraus prognostizieren
Velocity ist die Summe der Punkte, die ein Team pro Sprint tatsächlich fertigstellt. Fertig heißt: erfüllt die Definition of Done, nicht „fast fertig“. Nach drei bis fünf Sprints gibt es eine brauchbare Datenbasis.
Angenommen, ein Team hat in sechs Zwei-Wochen-Sprints 21, 25, 18, 27, 22 und 24 Punkte geschafft. Im Backlog stehen noch 240 Punkte.
- Bester Sprint: 240 ÷ 27
- 9 Sprints
- Mittelwert: 240 ÷ 22,8
- 11 Sprints
- Schwächster Sprint: 240 ÷ 18
- 14 Sprints
- Prognose bei Zwei-Wochen-Sprints
- 18 bis 28 Wochen
Beispielwerte. Die Spanne ergibt sich aus schlechtestem und bestem Sprint, der Mittelwert liegt bei 22,8 Punkten.
Diese Spanne ist ehrlicher als jede einzelne Zahl. Sie zeigt, dass die Fertigstellung zwischen vier und knapp sieben Monaten liegen kann, und sie wird mit jedem Sprint enger. Kommen neue Stories ins Backlog, wächst der Restumfang, und die Prognose verschiebt sich. Das ist kein Fehler der Methode, sondern genau die Information, die das Management braucht.
Für die Budgetplanung kann man Punkte in Geld übersetzen, aber nur über das ganze Team: Kosten eines Sprints geteilt durch die mittlere Velocity ergibt Kosten pro Punkt. Diese Zahl taugt für Prognosen, nicht für die Bewertung einzelner Stories. Wie man vor Projektbeginn ohne Velocity-Daten schätzt, erklärt der Beitrag zur Aufwandsschätzung in Softwareprojekten.
Die vier häufigsten Missbräuche
Velocity als Leistungsziel
Sobald ein Team „mehr Punkte“ liefern soll, werden Stories größer geschätzt. Die Velocity steigt, die Lieferung nicht.
Punkte in Stunden umrechnen
Wer festlegt, dass ein Punkt sechs Stunden entspricht, hat Stundenschätzung mit Extraschritt eingeführt.
Teams vergleichen
30 Punkte bei Team A und 50 bei Team B sagen nichts über Produktivität. Die Maßstäbe sind verschieden.
Halbfertiges zählen
Eine Story, die zu 80 Prozent fertig ist, zählt mit null Punkten. Sonst wird die Velocity geschönt, und die Prognose stimmt nicht mehr.
Das klingt hart. Es hat aber einen nützlichen Nebeneffekt: Teams lernen, Stories kleiner zu schneiden, weil eine große Story, die über das Sprintende rutscht, die Velocity sichtbar drückt. Kleine Stories sind besser planbar, und die Prognose aus dem letzten Abschnitt wird schneller verlässlich. Wer regelmäßig Stories mit 13 oder mehr Punkten in den Sprint nimmt, sollte deshalb zuerst am Zerlegen arbeiten, nicht an der Schätzung.
Wann du auf Story Points verzichten kannst
Der Scrum Guide 2020 schreibt keine Schätzmethode vor. Er sagt nur, dass die Developers für die Größeneinschätzung verantwortlich sind. Manche erfahrenen Teams zählen deshalb einfach Stories pro Sprint, nachdem sie alle auf ähnliche Größe zerlegt haben. Das funktioniert, wenn Stories konsequent klein bleiben, also in zwei bis drei Tagen umsetzbar sind.
Für Teams in der Anfangsphase oder mit stark unterschiedlich großen Stories bleiben Punkte das bessere Werkzeug. Und für Verträge mit externen Dienstleistern sind sie ungeeignet, weil die Einheit nur innerhalb eines Teams Bedeutung hat. Dort gehören Personentage oder Budgets hin, wie im Vergleich Festpreis oder Time and Material beschrieben.
Wer ein externes Team beauftragt und dessen Velocity verstehen will, sollte sich die Sprint-Historie zeigen lassen statt einer Durchschnittszahl. Ein Studio wie OnlineBuilders beschreibt seine Arbeitsweise offen, und das ist ein guter Maßstab für Transparenz bei jedem Anbieter.
Nächster Schritt: Leg mit deinem Team in der nächsten Planung drei Referenz-Stories fest und hänge die Tabelle sichtbar auf. Erst danach lohnt sich Planning Poker.
Häufige Fragen
Wie viele Stunden sind ein Story Point?
Keine feste Zahl, und genau das ist der Sinn. Punkte messen Größe und Komplexität relativ zueinander. Wer eine feste Umrechnung einführt, schätzt wieder in Stunden, nur mit anderem Namen.
Kann man Story Points zwischen Teams vergleichen?
Nein. Jedes Team hat seine eigene Referenz-Story, 8 Punkte bei Team A bedeuten etwas anderes als bei Team B. Velocity-Vergleiche zwischen Teams führen fast immer zu Punkteinflation.
Schreibt Scrum Story Points vor?
Nein. Der Scrum Guide 2020 erwähnt Story Points nicht. Er sagt nur, dass die Developers für die Größeneinschätzung zuständig sind. Story Points sind eine verbreitete Praxis, aber keine Pflicht.
Was tun bei einer 40 oder 100 auf der Karte?
Die Story ist zu groß oder zu unklar, um sie sinnvoll zu schätzen. Sie wird als Epic behandelt und vor der Planung in kleinere Stories zerlegt.
