Agile Velocity und Story Points
Velocity ist das Maß, wie viel Arbeit ein agiles Team in einem Sprint abschließt, ausgedrückt in Story Points. Sie ist der nützlichste Planungs-Input für ein Scrum-Team — und eine der am häufigsten missbrauchten Metriken.
Was Velocity misst
Velocity misst Durchsatz — die Anzahl der Story Points, die ein Team bis zur Definition of Done in einem Sprint abschließt.
Velocity misst keine individuelle Produktivität. Sie misst keine Codequalität. Sie misst eine Sache: wie viele Story Points in diesem Sprint abgeschlossen wurden.
Als Planungs-Input für ein einzelnes Team auf einer bekannten Codebasis ist sie sehr zuverlässig. Als Vergleichsmetrik zwischen Teams ist sie bedeutungslos.
Wie man Sprint-Velocity berechnet
Sprint-Velocity ist die Summe der abgeschlossenen Story Points in einem Sprint. Nicht fertige Stories zählen nicht.
Velocity = Σ (Story Points abgeschlossener Stories) pro Sprint
Planungs-Velocity — die Zahl für Sprint Planning — ist typischerweise ein gleitender Durchschnitt der letzten 3–5 Sprints.
Gleitender Durchschnitt Velocity = (Sprint N + Sprint N-1 + Sprint N-2 + Sprint N-3) / 4
Nicht die Velocity eines einzelnen Sprints für die Planung verwenden.
Velocity für Sprint Planning verwenden
Velocity ist der Input, der Story Points in Kapazität umwandelt.
- Bei 80–90 % der Velocity planen: Puffer für unerwartete Arbeit lassen.
- Für Teamverfügbarkeit anpassen: wenn das Team in diesem Sprint 80 % Kapazität hat, bei 80 % der angepassten Velocity planen.
- Velocity jeden Sprint aktualisieren: den ältesten Sprint aus dem gleitenden Durchschnitt herausnehmen und den neuesten hinzufügen.
Release-Prognose mit Velocity
Velocity ermöglicht Release-Prognosen: bei bekannter Backlog-Größe in Story Points, wann wird das Team fertig?
Einfache Prognose: verbleibende Story Points zählen, durch gleitende Durchschnitts-Velocity dividieren.
Beispiel: 200 Punkte verbleibend ÷ 40 Punkte/Sprint Durchschnitt = 5 Sprints ≈ 10 Wochen bei 2-Wochen-Sprints.
Das ist eine Prognose, kein Commitment.
Bereichsbasierte Prognose: Bester Fall (Velocity = 90. Perzentile), Schlechtester Fall (Velocity = 10. Perzentile).
Velocity-Anti-Pattern vermeiden
Velocity ist nur nützlich, wenn sie nicht manipuliert wird.
- Velocity als Leistungsmetrik verwenden: wenn Teams für hohe Velocity belohnt werden, steigen Schätzungen. Bekannt als Goodharts Gesetz.
- Velocity zwischen Teams vergleichen: verschiedene Teams kalibrieren ihre Story-Point-Skalen unabhängig.
- Unfertige Stories zählen: teilweiser Velocity-Bonus führt zu willkürlicher Variabilität.
- Erwarten, dass Velocity unendlich steigt: reife Teams erreichen eine stabile Velocity-Bandbreite.
Velocity FAQ
Was ist eine gute Velocity für ein Scrum-Team?
Es gibt keine universelle "gute" Velocity. Velocity hat nur Bedeutung im Verhältnis zu den historischen Daten deines eigenen Teams.
Warum ist unsere Velocity plötzlich gesunken?
Häufige Ursachen: Teamzusammensetzungsänderung, Sprint mit ungewöhnlich komplexen Stories, erhöhte Unterbrechungslast.
Sollen wir Spikes in Story Points schätzen?
Spikes werden meist in Zeit statt Story Points geschätzt und viele Teams schließen sie aus den Velocity-Berechnungen aus.
Wie lange dauert es, bis die Velocity sich stabilisiert?
Die meisten Teams erreichen eine stabile Velocity-Bandbreite innerhalb von 4–6 Sprints.
Schätze dein Sprint Backlog mit kostenlosem Online-Planning-Poker