Ist die Geschwindigkeit eine aussagekräftige Kennzahl? Unser Fazit

Innerhalb des Teams ist sie sinnvoll, außerhalb des Teams jedoch schädlich. Die Velocity dient als Prognosegröße, an der sich das Team orientiert; sobald sie jedoch zu einem Ziel oder zu einem teamübergreifenden Vergleichsmaßstab wird, wird sie überbewertet und verliert jegliche Aussagekraft. Sie gehört nicht zu den Lieferkennzahlen von DORA.

Fast alle Beteiligten in der Debatte sind sich einig, dass die Geschwindigkeit niemals das Team verlassen sollte, und dennoch lässt fast jede Organisation dies zu. Genau diese Diskrepanz ist der Kern der Debatte. Die Kennzahl ist für eine bestimmte Aufgabe tatsächlich nützlich, für die anderen jedoch zuverlässig schädlich; daher muss das Urteil differenziert ausfallen.

Argumente dafür, dass Geschwindigkeit nützlich ist

Innerhalb des Teams leistet die Velocity echte Arbeit. Sie ermöglicht Ihnen Prognosen: Teilen Sie den verbleibenden Umfang durch den aktuellen Durchschnittswert des Teams, und Sie erhalten eine ungefähre Anzahl an Sprints, die Sie abschließen können. Sie ermöglicht es Ihnen, einen realistischen Sprint zu dimensionieren: Wählen Sie Stories aus, bis diese insgesamt etwa achtzig bis neunzig Prozent des aktuellen Durchschnittswerts ausmachen, und lassen Sie dabei Spielraum für Unvorhergesehenes. Und sie macht auf echte Veränderungen aufmerksam: Ein Rückgang um dreißig Prozent ist ein Signal, das ein Gespräch rechtfertigt – und kein Vorwurf.

Das Anliegen des Managements hinter der Verwendung von „Velocity“ als Kennzahl ist ebenfalls berechtigt und verdient eine faire Darstellung. Führungskräfte sind für die Erbringung der Leistungen verantwortlich und wünschen sich Transparenz darüber. „Wenn wir das Team nicht irgendwie messen können, woher wissen wir dann, dass es seine Leistungen erbringt?“ – das ist eine berechtigte Frage und kein Zitat eines Bösewichts. Das Problem ist nicht der Wunsch an sich. Das Problem ist, dass die Velocity hierfür das falsche Instrument ist.

Das Argument, dass Geschwindigkeit eine Falle ist

Richten Sie die Geschwindigkeit nach außen aus, und sie bricht auf vorhersehbare Weise ein. Legen Sie sie als Ziel fest („Steigerung der Geschwindigkeit um zwanzig Prozent in diesem Quartal“), und das Team kommt dieser Vorgabe nach, indem es denselben Arbeitsumfang größer auslegt, anstatt mehr davon zu erledigen. Verwandeln Sie ein paar „Dreier“ in „Fünfer“, und die Zahl steigt, ohne dass sich der Output tatsächlich erhöht. Dies ist Goodharts Gesetz, das in einem zweiwöchigen Zyklus wirkt, und es handelt sich dabei nicht um eine Hypothese: Selbst Mike Cohn, der führende Verfechter von Story-Punkten, räumt ein, dass schon der geringste Hinweis darauf, dass Geschwindigkeiten verglichen werden, zu einer allmählichen, aber beständigen Inflation der Punkte führt.

Der teamübergreifende Vergleich ist noch problematischer, da er zwar streng erscheint, aber bedeutungslos ist. Zwei Teams, die denselben Backlog bewerten, kommen zu unterschiedlichen Zahlen, da sie sich an unterschiedlichen Referenz-Stories orientieren – und genau darin liegt der Sinn der relativen Schätzung. Das Bilden von Durchschnittswerten oder Ranglisten verfälscht die Kalibrierung beider Teams, nur um ein Dashboard zu füllen. Ein deutliches Anzeichen dafür, dass eine Organisation hier falsch liegt, ist, wenn eine Führungskraft ihre Teams persönlich vor „Velocity als KPI“ schützen muss – eine Abhilfe, die genau so lange funktioniert, wie diese Person in ihrer Rolle verbleibt.

In welchen Fällen wir unsere Meinung ändern würden

Wir würden „Velocity“ ohne Vorbehalt für jedes Team beibehalten, das diese Kennzahl ausschließlich zur Prognose und Planung nutzt und sie niemals über den Teamrahmen hinausgibt. Bei einer solchen Verwendung stellt sie keineswegs eine Falle dar. Es handelt sich lediglich um Berechnungen, die das Team für sich selbst durchführt.

In zwei Fällen würden wir darauf gänzlich verzichten. Erstens: Wenn die Arbeit so einheitlich ist, dass das Zählen von Stories ebenso aussagekräftig ist wie das Addieren von Punkten, dann stellt die Velocity einen Mehraufwand dar, und der Durchsatz ist einfacher zu messen und lässt sich schwerer manipulieren. Zweitens, wenn die Organisation nicht davon ablassen kann, die Zahl als Druckmittel einzusetzen. Wenn sich dieser Spiralprozess kulturell festgesetzt hat und kein Einzelner ihn aufhalten kann, ist es der ehrliche Weg, die Produktion der missbrauchten Zahl einzustellen und auf Flusskennzahlen umzusteigen, die nicht missbraucht werden.

Die praktische Umsetzung

• Die Geschwindigkeit misst das Tempo, nicht die Produktivität. Sagen Sie dies laut im Raum, sobald jemand dies zum ersten Mal als Leistungskennzahl interpretiert.
• Vergleichen Sie niemals Teams, legen Sie dies niemals als Ziel fest und rechnen Sie es niemals in erwartete Stunden pro Entwickler um. All dies ist ein und derselbe Fehler, der sich nur in unterschiedlicher Form zeigt.
• Berichten Sie Ergebnisse nach oben, nicht Punktestände. Die fünf Kennzahlen von DORA – Bereitstellungshäufigkeit, Vorlaufzeit für Änderungen, Ausfallrate bei Änderungen, Wiederherstellungszeit und Nacharbeitsrate bei Bereitstellungen – messen die Leistungserbringung, ohne Spielraum für Manipulationen zu lassen, und haben im Gegensatz zu Punkteständen teamübergreifend dieselbe Bedeutung. Das ist der Kennzahlensatz, den die Führungsebene tatsächlich wünscht.
• Passen Sie die Punktzahl des Backlogs nicht an, wenn das Team schneller arbeitet. Die Stories sind nicht kleiner geworden. Das Team ist schneller geworden, und die Velocity-Zahl wird von selbst steigen. Eine Anpassung der Punktzahl, um die Velocity konstant zu halten, ist wie eine Rückwärtsbewegung der Ratsche und beeinträchtigt die Prognose in gleicher Weise.

Die Velocity dient dem Team als Orientierungshilfe, nicht den Führungskräften als Bewertungsmaßstab. Bleibt sie innerhalb des Teams, ist sie eine der nützlichsten Kennzahlen in der agilen Entwicklung. Wird sie nach außen getragen, wird sie zum deutlichsten Beispiel für einen „Power“-Fehlermodus, den es gibt.

Häufig gestellte Fragen

Ist die Geschwindigkeit ein Produktivitätskennwert?

Nein. Die Velocity misst das Tempo, nicht die Produktivität: Sie gibt an, wie viele Story-Punkte ein bestimmtes Team pro Sprint gemäß seiner eigenen Kalibrierung abschließt. Sie sagt nichts darüber aus, ob die Arbeit wertvoll war, und war auch nie dafür konzipiert. Zu den Lieferkennzahlen von DORA gehört die Velocity ebenfalls nicht.

Können Sie die Geschwindigkeit zwischen den Teams vergleichen?

Nein. Zwei Teams, die denselben Arbeitsumfang bewerten, kommen zu unterschiedlichen Geschwindigkeitswerten, da sie unterschiedliche Referenz-Stories verwenden – und genau darin liegt der Sinn der relativen Schätzung. Ein Vergleich dieser Werte ist vergleichbar mit dem Vergleich zweier Thermometer mit unterschiedlichen Nullpunkten. Mike Cohn, der sich für Story-Punkte einsetzt, räumt ein, dass bereits der geringste Anschein eines Vergleichs der Geschwindigkeiten zu einer konsequenten Aufblähung der Punktzahlen führt.

Was sollten wir der Geschäftsleitung anstelle der Velocity melden?

Berichten Sie über Ergebnisse, nicht über Punktestände. Die fünf Kennzahlen von DORA (Bereitstellungshäufigkeit, Vorlaufzeit für Änderungen, Ausfallrate bei Änderungen, Zeit bis zur Wiederherstellung des Betriebs und, seit 2024, Nacharbeitsrate bei Bereitstellungen) messen die Leistungserbringung auf eine Weise, die keinen Spielraum für Manipulationen lässt und in jedem Team dasselbe bedeutet, auch wenn DORA davor warnt, Teams anhand dieser Kennzahlen in eine Rangfolge zu bringen. Die Velocity bleibt als Planungsgrundlage innerhalb des Teams; die Kennzahlen von DORA sind das, worauf die Führungsebene tatsächlich achten sollte.

Weiterführende Literatur

• Geschwindigkeit: Wozu sie dient und wie man sie berechnet: die Grundlagen und warum sie in dem Moment versagt, in dem sie zum Ziel wird.
• Story-Points vs. #NoEstimates: Der Kampf in der frühen Phase – Was die Zahl wert ist, bevor sie zu einer Prognose wird.
• Story-Punkte vs. Stunden: Warum die Umrechnung beider Größen in Stunden das Problem, das durch die Velocity ersetzt wird, erneut hervorruft.
• Was ist ein Burndown-Diagramm?: Die Verfolgung der zugesagten Punkte innerhalb eines Sprints – eine ehrliche Darstellung der Zahlen.
• Agiles Theater: Der „Power Failure“-Modus – wie Kennzahlen wie die Velocity zu Kontrollinstrumenten werden.