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. DORA hat sie bewusst aus den Lieferkennzahlen herausgelassen.

Fast alle Beteiligten in dieser Debatte sind sich einig, dass die Geschwindigkeit niemals das Team verlassen sollte, und dennoch lässt fast jede Organisation dies dennoch 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 ausliefern können. Damit können Sie [einen realistischen Sprint dimensionieren]:/guides/sprint-planning-guide/velocity-and-capacity/ Wählen Sie Stories aus, bis diese zusammen etwa achtzig bis neunzig Prozent des aktuellen Durchschnitts 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 legitim und verdient es, fair dargelegt zu werden. 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, ob es seine Leistungen erbringt?“ – das ist eine berechtigte Frage und kein Satz, den ein Bösewicht sagen würde. Das Problem ist nicht der Wunsch an sich. Das Problem ist, dass die Velocity das falsche Instrument dafür 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 („Erhöhen Sie die Geschwindigkeit in diesem Quartal um zwanzig Prozent“), und das Team kommt dem 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 das Goodhart-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 Velocities verglichen werden, zu einer allmählichen, aber beständigen Punktinflation 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 dieser Rolle verbleibt.

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

Wir würden „Velocity“ ohne Vorbehalt für jedes Team beibehalten, das sie ausschließlich zur Prognose und Planung nutzt und sie niemals über den Teamrahmen hinaus weitergibt. 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 vollständig verzichten. Erstens: Wenn die Arbeit so einheitlich ist, dass das Zählen von Story-Prognosen sowie das Addieren von Punkten ausreicht, stellt die Velocity einen Mehraufwand dar, und der Durchsatz ist einfacher zu messen und schwerer zu manipulieren. Zweitens: wenn die Organisation nicht davon ablassen kann, die Zahl als Waffe einzusetzen. Wenn sich dieser Spiralprozess kulturell verfestigt hat und kein Einzelner ihn aufhalten kann, ist es der ehrliche Weg, die Erhebung der missbrauchten Kennzahl einzustellen und auf Flusskennzahlen umzusteigen, die nicht missbraucht werden.

Die praktische Umsetzung

• Die Geschwindigkeit misst das Tempo, nicht die Produktivität. Sprechen Sie dies laut aus, sobald jemand dies zum ersten Mal als Leistungskennzahl interpretiert.
• Vergleichen Sie niemals Teams miteinander, setzen Sie sich dies niemals als Ziel und rechnen Sie es niemals in erwartete Arbeitsstunden 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 vier Schlüssel von DORA, die Häufigkeit von Bereitstellungen, die Vorlaufzeit für Änderungen, die Ausfallrate bei Änderungen und die Zeit bis zur Wiederherstellung – messen Sie die Leistung, ohne Manipulationen zu begünstigen, und sorgen Sie dafür, dass diese Kennzahlen – im Gegensatz zu Punkten – teamübergreifend einheitlich definiert sind. Das ist der Kennzahlensatz, den die Führungskräfte tatsächlich wünschen.
• 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 auf dieselbe Weise.

Die Velocity dient dem Team als Orientierungshilfe, nicht als Bewertungsmaßstab für Führungskräfte. 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 Machtversagen-Modus, das 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 wurde auch nie dafür konzipiert. Genau aus diesem Grund schließt die DORA-Studie die Velocity bewusst aus ihren Lieferkennzahlen aus.

Können Sie die Geschwindigkeit der verschiedenen Teams miteinander vergleichen?

Nein. Zwei Teams, die denselben Arbeitsumfang bewerten, kommen zu unterschiedlichen Velocity-Werten, 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-Points ausspricht, räumt ein, dass bereits der geringste Hinweis darauf, dass Velocity-Werte verglichen werden, 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 vier Schlüsselkennzahlen von DORA (Bereitstellungshäufigkeit, Vorlaufzeit für Änderungen, Ausfallrate bei Änderungen und Zeit bis zur Wiederherstellung des Betriebs) messen die Leistungserbringung auf eine Weise, die keinen Spielraum für Manipulationen lässt und teamübergreifend vergleichbar ist. Die Velocity bleibt als Planungsgrundlage innerhalb des Teams; die vier Schlüsselkennzahlen sind das, worauf die Führungsebene tatsächlich achten sollte.

Weiterführende Literatur

• Geschwindigkeit: Wozu dient sie und wie berechnet man sie?: Die physikalischen Grundlagen und warum sie in dem Moment versagt, in dem sie zum Ziel wird.
• Story Points vs. #NoEstimates: Der Kampf im Vorfeld: 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 wieder aufwirft, das durch die Velocity eigentlich beseitigt werden soll.
• Was ist ein Burndown-Diagramm?: Verfolgung der im Rahmen eines Sprints festgelegten Punkte – eine ehrliche Darstellung der Zahlen.
• Agiles Theater: Der „Power Failure“-Modus: Wie Kennzahlen wie die Velocity zu Kontrollinstrumenten werden.