In fast jedem Sprint-Review, das ich gesehen habe, taucht irgendwann diese Folie auf: ein Balkendiagramm, Velocity über die letzten Sprints. Die Balken schwanken um einen Mittelwert, jemand sagt „stabil bei rund vierzig Punkten", und alle nicken, als wäre damit etwas gesagt.
Es ist nichts gesagt. Und das ist noch der harmlose Fall — der gefährliche beginnt, wenn jemand aus den Balken Schlüsse zieht.
Was Velocity wirklich misst
Velocity ist die Summe der Story Points, die ein Team pro Sprint abschliesst. Und Story Points sind — das vergisst man leicht — Schätzungen des Teams über sich selbst. Keine Masseinheit, kein Standard, keine Währung. Ein interner Daumenwert, erfunden, damit ein Team seine eigene Sprintplanung kalibrieren kann.
Das heisst: Velocity misst nicht, wie viel Wert entsteht. Sie misst nicht einmal, wie viel Arbeit entsteht. Sie misst, wie viele selbstvergebene Punkte ein Team sich selbst gutschreibt.
Velocity ist der Drehzahlmesser, nicht der Tacho. Sie zeigt, wie schnell der Motor dreht — nicht, ob das Auto vorwärtsfährt. Ein Team kann mit hoher Drehzahl im Leerlauf stehen: viele Punkte, Features, die niemand nutzt, null Bewegung beim Kunden. Und ein Team kann mit niedriger Drehzahl im richtigen Gang genau das liefern, was den Unterschied macht.
Für den Fahrer ist der Drehzahlmesser nützlich — er hilft beim Schalten. Fürs Ziel ist er irrelevant. Niemand fragt nach der Ankunftszeit und bekommt gerne die Drehzahl genannt.
Der Erfinder bereut
Man muss das nicht mir glauben. Ron Jeffries — einer der Unterzeichner des Agilen Manifests und der Mann, der Story Points miterfunden hat — schreibt öffentlich, dass er die Erfindung inzwischen wahrscheinlich bereut. Seine Begründung ist präzise: Story Points wurden gebaut, um Planungsgespräche im Team zu vereinfachen. Sobald sie das Team verlassen — als Vergleich zwischen Teams, als Leistungsnachweis nach oben, als Zielvorgabe — richten sie mehr Schaden an als Nutzen. Martin Fowler, ebenfalls Manifest-Mitunterzeichner, argumentiert in dieselbe Richtung: Story Points sind derart anfällig für Missbrauch, dass man Schätzungen besser ganz überdenkt, als sie zur Steuerungsgrösse zu machen.
Genau dorthin sind sie aber gewandert. Und was dann passiert, ist keine Charakterfrage, sondern ein Naturgesetz der Messung.
Goodharts Gesetz, live im Planning
Die Sozialwissenschaft kennt das Muster seit den Siebzigern; die bekannteste Formulierung stammt von der Anthropologin Marilyn Strathern: Sobald eine Messgrösse zum Ziel wird, hört sie auf, eine gute Messgrösse zu sein.
Bei Velocity kannst du dabei zusehen, und zwar in Echtzeit. Wird Velocity nach oben berichtet, beginnt die Inflation — nicht durch Betrug, sondern durch hundert kleine, einzeln vernünftige Entscheidungen: Die Fünf wird im Zweifel zur Acht. Die grosse Story wird in drei kleine geteilt, die zusammen mehr Punkte tragen als das Original. Refactoring bekommt plötzlich Punkte. Nach vier Quartalen hat sich die Velocity verdoppelt, und es kommt exakt gleich viel beim Kunden an.
Das Tückische: Die Kurve sieht aus wie Verbesserung. Das Management sieht steigende Balken und glaubt, die Transformation wirkt. In Wahrheit hat es dem Team beigebracht, den Drehzahlmesser zu manipulieren — und gleichzeitig die einzige legitime Funktion der Punkte zerstört, nämlich die interne Planbarkeit. Eine Kennzahl, die zum Ziel wurde, lügt in beide Richtungen.
Was stattdessen zählt
Die unbequeme Wahrheit hinter der Velocity-Folie: Sie beantwortet eine Frage, die niemand gestellt hat. Stakeholder wollen zwei Dinge wissen — Wann kommt es an? Und: Bringt es etwas? Für beide gibt es bessere Antworten.
Für „Wann kommt es an?": Durchlaufzeit und Durchsatz. Wie lange braucht ein Anliegen von „angenommen" bis „beim Kunden" — und wie viele Anliegen schafft das System pro Woche? Das sind Kalenderzeit und Stückzahl: nicht manipulierbar durch Umschätzen, vergleichbar über Zeit, und für jeden Stakeholder ohne Übersetzung verständlich. Daniel Vacanti, dessen «Actionable Agile Metrics» das Standardwerk zu diesen Kennzahlen ist, zeigt zudem, dass sich daraus belastbarere Prognosen ableiten lassen als aus jeder Punktschätzung — aus der eigenen Historie statt aus dem Bauchgefühl. Es sind dieselben Grössen, auf denen die DORA-Forschung ihre Delivery-Metriken aufbaut — Lead Time und Deployment-Häufigkeit, ergänzt um Fehlerrate und Wiederherstellungszeit, damit Tempo nicht auf Kosten der Stabilität geht. Wo diese Zeit heute versickert, steht im Engpass-Artikel — Spoiler: selten beim Entwickeln.
Für „Bringt es etwas?": ein Outcome pro Initiative. Die beobachtbare Veränderung, die schon bei der Anforderung hätte benannt werden müssen: Der Monatsabschluss dauert zwei Stunden statt zwei Tage. Die Support-Tickets zum Login sind um die Hälfte gefallen. Wenn es diese Grösse nicht gibt, ist das kein Messproblem — dann wurde gebaut, ohne dass jemand gesagt hat, was besser werden soll.
Beides zusammen — Fluss-Kennzahlen plus Wirkungsnachweis — ersetzt die Velocity-Folie vollständig. Und beides gehört zusammen: Fluss ohne Wirkung ist Geschäftigkeit, Wirkung ohne Fluss ist Zufall.
Der eine Eingriff
Wenn du nur eine Sache änderst, dann diese:
Nimm Velocity aus jedem Bericht, der das Team verlässt. Ersetze die Folie durch zwei Zahlen: die mediane Durchlaufzeit — und ein Outcome, das sich seit dem letzten Review verändert hat.
Velocity darf bleiben, wo sie hingehört: im Planning, als interner Daumenwert für die Frage „wie viel passt in den Sprint". Dort ist sie harmlos und sogar nützlich. Ausserhalb des Teams hat sie nichts verloren — nicht, weil sie geheim wäre, sondern weil sie dort nur zwei Dinge auslösen kann: falsche Schlüsse oder Goodharts Gesetz.
Die erste Review mit der neuen Folie wird unbequem, denn die Durchlaufzeit ist fast immer peinlicher als die Velocity-Kurve. Genau deshalb ist sie die richtige Zahl: Sie zeigt das Problem, an dem sich arbeiten lässt, statt der Kurve, an der sich schrauben lässt.
Velocity ist nicht böse. Sie ist ein Werkzeug für eine einzige, kleine Aufgabe — Sprintplanung im Team — das zur wichtigsten Kennzahl ganzer Organisationen befördert wurde. Der Fehler liegt nicht im Werkzeug. Er liegt in der Beförderung.
Nächste Schritte
Wenn du wissen willst, wo die Durchlaufzeit tatsächlich verloren geht: In den Wartespalten, nicht beim Entwickeln. → Wo der Engpass auf deinem Board sichtbar wird
Wenn niemand sagen kann, welches Outcome eine Initiative verändern soll: Dann kam die Arbeit als bestellte Lösung ins Backlog. → Eine Anforderung ist keine Lösung - und eine Lösung ist keine Anforderung
Wenn getestet werden soll, ob etwas wirkt, bevor es gross gebaut wird: → Warum sich Teams in Discovery verlieren - und woran du es erkennen kannst
Wenn der Rhythmus fehlt, in dem solche Zahlen regelmässig auf den Tisch kommen: → Heartbeat im Scrum Team: Warum feste Strukturen der Schlüssel zur Effizienz sind
Ersetz die Folie in deinem nächsten Review und schreib mir, wie die Stakeholder reagiert haben. → Taleon LinkedIn
Quellen
- Jeffries, R. — «Story Points Revisited», ronjeffries.com, 2019 (der Miterfinder über den Missbrauch von Story Points ausserhalb des Teams). https://ronjeffries.com/articles/019-01ff/story-points/Index.html
- Fowler, M. — Beiträge zu Schätzung und deren Missbrauch, martinfowler.com (u. a. «PurposeOfEstimation»). https://martinfowler.com/bliki/PurposeOfEstimation.html
- Vacanti, D. — «Actionable Agile Metrics for Predictability», ActionableAgile Press, 2015 (Standardwerk zu Durchlaufzeit, Durchsatz und flussbasierten Prognosen). https://actionableagile.com
- Strathern, M. — «'Improving ratings': audit in the British University system», European Review, 5(3), 1997 (die verbreitete Formulierung von Goodharts Gesetz). https://doi.org/10.1002/(SICI)1234-981X(199707)5:3<305::AID-EURO184>3.0.CO;2-4
- DORA / Google Cloud — die vier Delivery-Kennzahlen (Lead Time, Deployment Frequency, Change Failure Rate, Time to Restore). https://dora.dev/guides/dora-metrics-four-keys/
