Beiträge

Sprint Velocity: richtig messen, prognostizieren und nicht missbrauchen

Illustration eines Sprint-Dashboards mit einer Tacho-Anzeige und einer Reihe ansteigender Balkendiagramme für die pro Sprint abgeschlossenen Story Points, modern-flacher redaktioneller Stil in kräftigen Lila- und Blautönen, ein kleines agiles Team betrachtet das Diagramm gemeinsam

Kelly Lewandowski

Zuletzt aktualisiert am 07/06/20268 Min. Lesezeit

Velocity ist die agile Metrik, die sich am einfachsten berechnen und am einfachsten ruinieren lässt. Zähl die Story Points zusammen, die dein Team letzten Sprint abgeschlossen hat. Das war's. Der Ärger beginnt in dem Moment, in dem jemand diese Zahl als Ziel, als Produktivitätsbewertung oder als präzises Lieferversprechen behandelt. Velocity hat genau zwei legitime Aufgaben: dir grob dabei zu helfen zu prognostizieren, wann ein Arbeitspaket fertig sein wird, und dem Team einen Realitätscheck zu geben, wie viel es in den nächsten Sprint ziehen sollte. Für alles andere genutzt richtet sie mehr Schaden als Nutzen an. Hier erfährst du, wie du beide Aufgaben gut erledigst und wie du den Missbrauch erkennst, bevor er um sich greift.

Was Sprint Velocity wirklich ist

Velocity ist die Anzahl der Story Points, die dein Team in einem Sprint abgeschlossen hat. Abgeschlossen heißt fertig im Sinne deiner Definition of Done, nicht "im QA" oder "fast gemerged". Halb fertige Arbeit zählt null. Eine übertragene Story zählt ihre Punkte in dem Sprint, in dem sie tatsächlich fertig wird, nicht in dem, in dem sie begonnen wurde. Das ist die gesamte Definition. Velocity misst weder Aufwand noch Stunden noch wie hart die Leute gearbeitet haben. Sie misst den Output in der teameigenen Story-Point-Währung, und genau deshalb hat sie nur innerhalb dieses einen Teams eine Aussagekraft.

Punkte sind teamrelativ

Die Punkte eines Teams sind auf dieses Team kalibriert. Die 8 des einen Teams ist die 3 eines anderen. Genau diese Tatsache macht die meisten Velocity-Vergleiche wertlos, und wir kommen darauf zurück.

Wie du sie berechnest (und warum eine einzelne Zahl lügt)

Die Grundformel ist ein Durchschnitt über deine letzten Sprints: Durchschnittliche Velocity = abgeschlossene Punkte gesamt ÷ Anzahl der Sprints Nimm mindestens 3 Sprints, idealerweise 6 oder mehr, und zähle nur Sprints mit weitgehend stabiler Teamzusammensetzung. Hier ein realistisch wirkender Verlauf über sechs Sprints:

22, 28, 19, 31, 24, 26

Abgeschlossene Punkte pro Sprint

Durchschnittliche Velocity

19–31

Tatsächliche Bandbreite

Der Durchschnitt liegt bei 25. Doch kein einziger Sprint hat tatsächlich 25 geliefert, und die reale Spanne reicht von 19 bis 31. Planst du jeden Sprint rund um die "25", übernimmst du dich in langsamen Sprints und füllst in schnellen zu wenig auf. Der Durchschnitt ist ein Ausgangspunkt für ein Gespräch, kein Vertrag. Deshalb gibt der Sprint-Velocity-Rechner neben dem Durchschnitt auch eine Bandbreite und einen Konsistenzwert aus. Füg deine letzten Sprints ein, und er verrät dir nicht nur den Mittelwert, sondern auch, wie verlässlich dieser Mittelwert ist. Ein Team mit 24, 25, 26 steht ganz anders da als eines mit 12, 38, 25, auch wenn beide einen Schnitt von 25 haben.

Prognose: arbeite mit Bandbreiten, nicht mit Einzelwerten

Hier geht der Großteil der Velocity-Ratschläge schief. Der Klassiker lautet "Backlog ÷ durchschnittliche Velocity = Sprints bis fertig". Bei einem 200-Punkte-Backlog und einer durchschnittlichen Velocity von 25 sind das 8 Sprints. Sauber, selbstbewusst und mit ziemlicher Sicherheit falsch, weil so getan wird, als hätte deine Velocity keine Streuung. Deine Velocity hat aber eine Streuung, also sollte deine Prognose das auch haben. Die einfache, ehrliche Variante ist die Drei-Szenarien-Prognose: prognostiziere mit einer konservativen, einer wahrscheinlichen und einer optimistischen Velocity.

Szenario	Verwendete Velocity	200-Punkte-Backlog
Konservativ	Schnitt deiner 3 langsamsten Sprints (~22)	~10 Sprints
Wahrscheinlich	Gesamtdurchschnitt (25)	8 Sprints
Optimistisch	Schnitt deiner 3 schnellsten Sprints (~28)	~7 Sprints

Jetzt kannst du einem Stakeholder "7 bis 10 Sprints, am wahrscheinlichsten 8" sagen, statt einer einzelnen Zahl, die du später zurücknehmen musst. Wie Mike Cohn und andere seit Langem betonen, ist eine Aussage wie "wir sind zu 90 % sicher, dass das zwischen Sprint 7 und Sprint 10 landet" sowohl nützlicher als auch besser zu verteidigen als Scheingenauigkeit.

Nenne immer eine Bandbreite

Wenn jemand nach einem Datum fragt, gib zwei: das optimistische und das konservative. Eine Bandbreite kommuniziert Unsicherheit ehrlich und schützt dich, wenn die Realität irgendwo dazwischen landet, was fast immer der Fall ist.

Für Teams, die echte Wahrscheinlichkeiten wollen, ist die Monte-Carlo-Simulation der nächste Schritt. Statt drei handverlesener Szenarien rechnet sie tausende simulierter Zukünfte durch, indem sie zufällig aus deinen historischen Sprints zieht, und gibt die Ergebnisse dann als Perzentile aus: einen Abschluss im 50. Perzentil (Median), einen im 85., einen im 95. "85 % Chance, dass wir bis Sprint 9 fertig sind" ist eine weit stärkere Aussage, als sie ein Durchschnitt je treffen kann. Du brauchst keinen einzelnen Punktschätzwert, sondern eine Verteilung. Illustration eines sich von einem Startpunkt zur Zielflagge auffächernden Unsicherheitstrichters, mit mehreren Wahrscheinlichkeitspfaden in blauen und lila Verlaufsbändern, modern-flacher Vektorstil, ohne Text oder Zahlen

Illustration eines sich von einem Startpunkt zur Zielflagge auffächernden Unsicherheitstrichters, mit mehreren Wahrscheinlichkeitspfaden in blauen und lila Verlaufsbändern, modern-flacher Vektorstil, ohne Text oder Zahlen

Wie Teams Velocity missbrauchen

Scrum.org ist sogar so weit gegangen, einen Beitrag mit dem Titel "Story Points are not the Problem, Velocity is" zu veröffentlichen. Das Schätzen der Punkte ist meist harmlos; der Schaden entsteht durch das, was Manager mit der resultierenden Velocity-Zahl anstellen. Auf diese vier Fehlermuster solltest du achten.

⚖️Teams vergleichen

Team A schafft 40, Team B schafft 25, also ist Team A "produktiver". Falsch. Punkte sind teamrelativ, der Vergleich misst also nichts. Er bringt Team B nur bei, die Schätzungen aufzublähen.

📈Als Produktivitätskennzahl

In dem Moment, in dem Velocity zur Zahl wird, an der Leute gemessen werden, misst sie keinen Output mehr, sondern wie viel Druck das Team spürt. Goodharts Gesetz in Aktion.

🎯Als Verpflichtung

"Letzten Sprint waren es 30, also verpflichte dich auf 30." Das macht aus einer Prognose eine Quote und drängt das Team dazu, Schätzungen zu polstern, bis die Zahl sicher erreichbar ist.

🎲Aus einem einzelnen Sprint

Ein Sprint ist Rauschen. Ein Feiertag, ein Ausfall oder ein hartnäckiger Bug lassen ihn wild schwanken. Velocity bedeutet nur etwas als Trend über mehrere Sprints.

Der gemeinsame Nenner: jeder Missbrauch verwandelt Velocity von einem Werkzeug, das das Team nutzt, in ein Ziel, an dem das Team gemessen wird. Sobald dieser Umschwung passiert, wird die Zahl manipuliert und du verlierst das ehrliche Signal, mit dem du angefangen hast.

Die Inflations-Todesspirale

Setz ein Team unter Druck, seine Velocity zu steigern, und es wird das sofort tun, indem es dieselbe Arbeit klammheimlich höher schätzt. Die Velocity klettert, nichts wird schneller geliefert, und jetzt sind deine historischen Daten für die Prognose vergiftet. Die Metrik, die du optimieren wolltest, zerstört das Einzige, wofür sie gut war.

Velocity richtig gemacht

Als reines internes Planungshilfsmittel und nicht mehr verdient sich Velocity ihre Berechtigung. Eine kurze Checkliste, um sie ehrlich zu halten:

Zähle nur Arbeit, die laut deiner Definition of Done vollständig fertig ist.

Bilde den Schnitt über 6+ Sprints und achte auf den Trend, nicht auf eine einzelne Zahl.

Prognostiziere mit Bandbreiten oder Perzentilen, nie mit einem einzelnen Fertig-Datum.

Setze nach größeren Teamänderungen neu auf; alte Velocity lässt sich nicht übertragen.

Zeig Velocity nie auf einer Folie, die Teams oder Einzelpersonen vergleicht.

Halte das Schätzgespräch am Leben; die Diskussion zählt mehr als die Punkte.

Den letzten Punkt vergessen Teams am häufigsten. Velocity ist ein Nebenprodukt guter Schätzung, nicht ihr Ziel. Der Wert von Planning Poker liegt im Gespräch, das verborgene Komplexität sichtbar macht, bevor sie dich mitten im Sprint einholt. Die Zahl, die dabei herausfällt, ist bloß Buchhaltung.

Velocity ist nicht deine einzige Option

Wenn Velocity in deinem Team immer wieder als Waffe missbraucht wird oder deine Stories zu stark in der Größe schwanken, als dass Punkte stabil sein könnten, hast du Alternativen. Manche Teams verzichten ganz aufs Schätzen und prognostizieren direkt aus dem Durchsatz. Ein leichterer Schritt ist, Velocity zu behalten, sich aber für das, was sie schlecht kann, auf Flow-Metriken zu stützen. Durchsatz (pro Sprint fertiggestellte Items) und Cycle Time (wie lange ein Item von Start bis Fertig braucht) messen die Lieferung mit echten Zeitstempeln statt mit Schätzungen.

Frage	Beste Metrik
Wie viel in einen Sprint ziehen	Velocity oder Durchsatz
Wann ist dieser Backlog fertig	Monte Carlo auf Velocity/Durchsatz
Warum dauert die Arbeit so lange	Cycle Time und Work-in-Progress
Werden wir mit der Zeit besser	Cycle-Time-Trend

Die meisten reifen Teams nutzen am Ende beides: Velocity für das Gespräch auf Sprint-Ebene, Flow-Metriken für die Lieferprognose und das Aufspüren von Engpässen. Sie beantworten unterschiedliche Fragen, und keine von beiden ist eine Produktivitäts-Rangliste.

Das Fazit

Velocity ist eine Taschenlampe, kein Tacho. Sie hilft dem Team zu sehen, wie viel es ungefähr übernehmen kann und wann ungefähr ein Arbeitspaket fertig wird. Richte sie auf Menschen statt auf Arbeit, und sie sagt nicht mehr die Wahrheit. Verfolge sie über mehrere Sprints, prognostiziere in Bandbreiten und halte sie innerhalb des Teams. Wenn du die Zahlen schnell durchgerechnet brauchst, macht der Sprint-Velocity-Rechner aus deinen letzten Sprints in wenigen Sekunden einen Durchschnitt, eine realistische Bandbreite, einen Konsistenzwert und eine Backlog-Prognose. Für die Schätzseite, die ihn speist, hält Planning Poker den Fokus dort, wo er hingehört: auf dem Gespräch, nicht auf der Rangliste.

Mindestens 3 für einen groben Durchschnitt, aber 6 oder mehr, bevor du ihr für die Prognose vertraust. Bei weniger verzerrt ein einzelner ungewöhnlicher Sprint alles. Das Team sollte über diese Sprints hinweg außerdem einigermaßen stabil sein.

Nur wenn diese Items in Punkten geschätzt und innerhalb des Sprints fertig wurden. Viele Teams lassen Bugs und Supportarbeit ungeschätzt und erfassen sie separat, was die Velocity auf die geplante Feature-Lieferung fokussiert hält. Wähle einen Ansatz und bleib konsequent dabei, damit deine Historie vergleichbar bleibt.

Story Points sind pro Team kalibriert, also ist die 5 des einen Teams die 13 eines anderen. Die rohen Zahlen zu vergleichen misst nichts Reales und setzt Teams unter Druck, ihre Schätzungen aufzublähen. Brauchst du eine teamübergreifende Sicht, schau auf gelieferte Ergebnisse oder die Cycle Time, nicht auf Punkte.

Nein. Velocity misst Output in einer teamspezifischen Einheit, nicht gelieferten Wert oder aufgewendeten Aufwand. Ein Team kann seine Velocity steigern, ohne etwas Nützlicheres zu liefern, einfach indem es Arbeit höher schätzt. Behandle sie als Planungseingabe, nie als Leistungskennzahl.