Geschwindigkeit: Wozu dient sie und wie berechnet man sie?

Die Geschwindigkeit ist eine Eingangsgröße für Prognosen, kein KPI. Sobald man Teams daran misst, wird sie künstlich aufgebläht.

Die Velocity ist die durchschnittliche Anzahl an Story-Punkten, die ein Team pro Sprint in den letzten Sprints abgeschlossen hat. Das ist die gesamte Definition. Sie dient einem einzigen Zweck: der Prognose, wie viele Sprints die Umsetzung eines Backlogs in Anspruch nehmen wird, ausgehend von der tatsächlichen Lieferrate des Teams. Addieren Sie die verbleibenden Punkte, dividieren Sie diese durch die Velocity, und Sie erhalten eine Prognose. Das ist ehrlich gesagt das Einzige, wozu sie dient.

Jede andere Verwendung macht das Konzept zunichte. „Warum war die Velocity in diesem Sprint niedriger?“ verwandelt jede Retrospektive in eine Verteidigung der Zahl. „Team A hat eine höhere Velocity als Team B“ behandelt die unabhängigen Kalibrierungen zweier Teams als vergleichbar, obwohl sie es nicht sind. „Wir müssen die Velocity in diesem Quartal um 20 % steigern“ fordert das Team auf, die Zahl in die Höhe zu treiben, und das Team wird dies auch tun – indem es denselben Arbeitsumfang größer einschätzt, nicht indem es mehr davon erledigt. Goodharts Gesetz, angewendet auf einen zweiwöchigen Zyklus.

So berechnen Sie es

Nehmen Sie die in jedem der letzten drei bis fünf Sprints abgeschlossenen Punkte. Berechnen Sie den Durchschnitt. Das ist Ihre Velocity. Berücksichtigen Sie keine „außergewöhnlichen“ Sprints – diese außergewöhnlichen Sprints sind Teil des Signals, das Sie zu glätten versuchen. Zählen Sie übertragene Arbeit nicht doppelt. Zählen Sie teilweise abgeschlossene Stories überhaupt nicht mit; diese werden erst im Sprint gezählt, in dem sie tatsächlich fertiggestellt werden. Je einfacher die Berechnung, desto schwieriger ist es, das System zu manipulieren.

Die Geschwindigkeit stabilisiert sich, nachdem ein Team drei oder vier Sprints gemeinsam absolviert hat. Ein neues Team, eine neue Referenzstory, eine größere personelle Veränderung – all dies sind Gründe, den bisherigen Wert zu verwerfen und von Grund auf neu zu beginnen. Der Wert ist keine Eigenschaft der Methode; er ist eine Eigenschaft dieses Teams in diesem Zeitraum. Ein Team, das gestern zwei Mitglieder verloren hat, weist die Velocity von gestern für ein anderes Team auf.

Wie viele Story-Punkte pro Sprint?

Die Suche nach „wie viele Story-Punkte pro Sprint“ ist ein Kategorienfehler. Es gibt keinen branchenüblichen Wert, keine „richtige“ Zahl und keinen Tageswert pro Entwickler. Die Velocity ist der gemessene Durchsatz des Teams, und die einzig aussagekräftige Kennzahl ist der gleitende Durchschnitt der letzten Sprints des Teams. Fünfzehn Punkte, vierzig Punkte, hundert Punkte – keine dieser Zahlen ist richtig oder falsch. Sie sind auf die Referenz-Story des Teams abgestimmt.

Nutzen Sie die Velocity also für drei Dinge, und zwar ausschließlich für diese drei: um einen Termin für einen bekannten Umfang zu prognostizieren (Umfang ÷ Velocity = Anzahl der Sprints); entscheiden Sie, was in den nächsten Sprint passt (wählen Sie Stories aus, bis deren Gesamtumfang etwa 80–90 % des jüngsten Durchschnitts beträgt, und lassen Sie dabei Spielraum für Unvorhergesehenes); und erkennen Sie, wann sich etwas geändert hat (ein Rückgang um 30 % ist ein Signal, das eine Retrospektive rechtfertigt). Was Sie damit nicht tun können: die Velocity mit den Zahlen eines anderen Teams vergleichen, sie zur Bewertung des Teams heranziehen oder sie in „erwartete Stunden pro Entwickler und Tag“ umrechnen. All dies sind dieselben Fehler, die sich lediglich in unterschiedlicher Form zeigen.

Was läuft schief?

Die mit Abstand häufigste Fehlerquelle: Ein Manager interpretiert einen Velocity-Wert als Maß dafür, „wie produktiv dieses Team ist“. Dieser Wert wird in Statusbesprechungen zitiert, anschließend teamübergreifend verglichen und schließlich als Zielvorgabe festgelegt. Innerhalb von zwei Sprints hat das Team seine Größeneinteilung angepasst, um den Wert in die Höhe zu treiben – jede Story ist nun um 30 % größer als zuvor –, und die Velocity hat ihre ursprüngliche Bedeutung verloren. Die Prognose, die sie eigentlich liefern sollte, ist nun falsch.

Zweitens: der Vergleich von Teams. Zwei Teams, die denselben Backlog einschätzen, kommen zu unterschiedlichen Velocity-Werten, da sie unterschiedliche Referenz-Stories verwenden – genau darin liegt der Sinn der relativen Schätzung. Ein Vergleich dieser Werte ist vergleichbar mit dem Vergleich zweier Thermometer mit unterschiedlichen Nullpunkten. Die Zahlen haben nicht dieselbe Bedeutung, und wenn man sie so behandelt, als ob dies der Fall wäre, wird die Kalibrierung beider Teams verfälscht.

Wann sollte eine Neubewertung vorgenommen werden?

Eine Neubewertung bereits abgeschlossener Arbeiten beeinträchtigt die Arbeitsgeschwindigkeit. Die Neubewertung von übertragenen Arbeiten ist der einzige ehrliche Fall.

Jedes Quartal taucht dieselbe Frage auf: „Wir haben dies mit einer 5 bewertet, tatsächlich war es aber eine 13 – sollten wir die Bewertung anpassen?“ Der Instinkt, der „Ja“ sagt, ist derselbe Instinkt, der verlangt, dass jede Zahl rückwirkend korrekt sein muss, und dieser Instinkt ist falsch. Die Velocity ist die Geschwindigkeit, mit der das Team – bei der Kalibrierung, die es zu diesem Zeitpunkt hatte – die Arbeit abgeschlossen hat. Wenn man zurückgeht und die Punkte neu bewertet, wird auch die Kalibrierung neu festgelegt, und die Prognose, die zuvor funktioniert hat, funktioniert nicht mehr. „Das Team ist schneller geworden, daher sollten alte Stories kleiner sein“ – damit wird das einzige Signal beseitigt, dass sich das Team verbessert hat. „Diese 5 hat sich als 13 herausgestellt“ ist ein Signal zur Verfeinerung der Einstufung der nächsten ähnlichen Story, nicht eine Erlaubnis, die Historie dieser einen Story neu zu schreiben.

Der einzige Fall, in dem Sie eine Neubewertung vornehmen sollten, ist der Übertrag. Eine Story wurde nicht fertiggestellt, der Sprint neigt sich dem Ende zu, und die verbleibende Arbeit wird in das Arbeitspensum des nächsten Sprints übernommen. Diese verbleibende Arbeit unterscheidet sich wesentlich von dem, was zu Beginn veranschlagt wurde – das Team hat einen Teil davon bereits erledigt, mindestens eine Unbekannte entdeckt und hat nun einen klareren Überblick darüber, was noch zu tun ist. Bewerten Sie die Aufgabe erneut, als wäre sie neu, und nutzen Sie die ursprüngliche Schätzung dabei eher als Plausibilitätsprüfung denn als Vorgabe.

Vereinheitlichung der Arbeitsgeschwindigkeit teamübergreifend

Die Normalisierung ist in erster Linie ein SAFe-Ritual, um die Zahlen im Portfolio-Dashboard unter einen Hut zu bringen. Lehnen Sie dies ab, es sei denn, jemand in Ihrer Führungsetage benötigt dieses Dashboard tatsächlich.

Bei der Normalisierung einigen sich zwei oder mehr Teams auf eine gemeinsame Referenzgeschichte – in der Regel etwa „ein Personentag Arbeit für einen durchschnittlichen Ingenieur“ –, sodass eine 5 in Team A dasselbe bedeutet wie eine 5 in Team B und ihre Velocities addiert werden können. Die Methode funktioniert: Eine normalisierte 5 bedeutet tatsächlich für alle Teams, die sich darauf geeinigt haben, dasselbe. Das Problem ist jedoch, was Sie dafür aufgegeben haben. Sie haben die relative Schätzungsmethode jedes Teams gegen eine absolute eingetauscht – was eine verschleierte Schätzung der Dauer darstellt –, nur damit eine Zahl über Teams hinweg gemittelt werden kann, die weder eine gemeinsame Codebasis, noch einen gemeinsamen Stack noch ein gemeinsames Fachgebiet haben.

Wenn eine Prognose auf Portfolioebene tatsächlich der Finanzierung von Arbeitsleistungen dient (und nicht nur dem Vergleich von Teams), führen Sie die Normalisierung auf der Rollup-Ebene durch: Lassen Sie das Programmmanagement einen teambezogenen Punktemultiplikator festlegen, der einmalig kalibriert und nur selten angepasst wird, und wenden Sie diesen an, wenn die Zahlen zusammengefasst werden. Jedes Team nimmt weiterhin seine Schätzungen anhand seiner eigenen Referenzstory vor; der Multiplikator wandelt die Team-Velocity in die Währung des Portfolios um, und in den Verfeinerungssitzungen wird er nie zur Sprache gebracht. Wogegen Sie sich wehren sollten: eine Normalisierung, die innerhalb eines einzelnen Teams beginnt, und eine Normalisierung, die durchgeführt wird, um den Vergleich zwischen Teams zu erleichtern. Letzteres ist kein Anwendungsfall – es ist ein Anti-Muster mit einem geschliffenen Namen.

Velocity und KI-Entwicklungstools

Copilot, Cursor, Claude Code. Die Punkte ändern sich nicht. Die Geschwindigkeit hingegen schon – allerdings erst im Nachhinein.

Diese Frage taucht in jedem Team auf, das seit einigen Monaten einen KI-Programmierassistenten einsetzt: Wir liefern schneller aus – sollten wir daher das Backlog neu bewerten? Sollte die 3 aus dem letzten Quartal in diesem Quartal eine 5 sein? Die Antwort lautet „nein“, denn Story-Points haben nie das gemessen, was sich geändert hat. Story-Punkte messen relative Komplexität und Unsicherheit; der Assistent reduziert zwar die Tippphase für eine Story – manchmal sogar drastisch –, doch die Komplexität bleibt unverändert, die Unwägbarkeiten bleiben unverändert, das Integrationsrisiko und die Randfälle bleiben unverändert. Wenn Sie eine 5 auf eine 3 herabstufen, nur weil das Tool den Standardcode geschrieben hat und Sie wieder in Stunden schätzen, ist das ein Fehler.

Was sich ändert, ist die Geschwindigkeit. Dasselbe Team, das mit einem Assistenten die gleiche Art von Arbeit ausliefert, liefert pro Sprint mehr Punkte aus als noch vor sechs Monaten – nicht, weil die Punkte kleiner geworden sind, sondern weil das Team schneller darin geworden ist, Punkte in ausgelieferten Code umzuwandeln. Das ist die Zahl, die genau ihre Aufgabe erfüllt, und sie passt sich auf natürliche Weise an über drei oder vier Sprints hinweg an. Halten Sie die Referenzstory des Teams aktuell – eine, die mit den derzeit verwendeten Tools ausgeliefert wurde –, und die Kalibrierung berücksichtigt bereits jede vorhandene Beschleunigung.

Zwei Punkte, die es zu hinterfragen gilt: „Die Geschwindigkeit ist um 30 % gestiegen, lassen Sie uns 30 % mehr anstreben“ – dabei wird die Verbesserung doppelt gezählt: Der aktuelle Durchschnitt berücksichtigt bereits den KI-Effekt, daher sollten Sie ihn nicht noch einmal hochrechnen. „Alles ist kleiner geworden, lassen Sie uns das Backlog neu einschätzen“ ist die oben beschriebene Falle der Neuschätzung – die Stories sind nicht kleiner geworden, das Team ist schneller geworden, und die Prognose spiegelt dies bereits wider. Gerade bei Unsicherheiten helfen die Tools am wenigsten: Ein Assistent beschleunigt zwar Teile der Untersuchung eines Spikes, doch das, was der Spike zu ergründen versucht, ist dadurch nicht kleiner geworden.

Häufig gestellte Fragen

Wie viele Story-Punkte pro Sprint sind üblich?

Es gibt keinen branchenüblichen Richtwert. Die Geschwindigkeit ist der gemessene Durchsatz Ihres Teams – der gleitende Durchschnitt der in den letzten Sprints abgeschlossenen Punkte. Fünfzehn, vierzig, hundert: Keine dieser Zahlen ist richtig oder falsch, da jede auf eine andere Referenzstory abgestimmt ist.

Wie viele Story-Punkte pro Sprint und Entwickler?

Berechnen Sie keinen solchen Wert. Ein Satz pro Entwickler verwandelt Story-Punkte wieder in verschleierte Arbeitsstunden und lädt zu dem Vergleich zwischen einzelnen Personen ein, den diese Methode eigentlich vermeiden soll. Die Velocity ist eine Teamkennzahl, nicht die Summe einzelner Quoten.

Wie viele Story-Punkte umfasst ein zweiwöchiger Sprint?

Unabhängig davon, wie viele Ihr Team in der Vergangenheit in einem zweiwöchigen Sprint abgeschlossen hat – messen Sie dies, legen Sie jedoch kein Ziel fest. Wählen Sie Stories aus, bis deren Gesamtumfang etwa 80–90 % Ihres jüngsten Durchschnitts beträgt, und lassen Sie Spielraum für Unvorhergesehenes.

Was ist eine gute Velocity für ein Scrum-Team?

Ein stabiler Wert. „Ist unsere Geschwindigkeit gut?“ – diese Frage bringt das System zum Einsturz: Sobald die Geschwindigkeit bewertet wird, steigen die Zahlen in die Höhe, und nichts wird tatsächlich schneller ausgeliefert. Eine gute Geschwindigkeit ist eine, auf die man planen kann, und keine Zahl, die ständig weiter steigt.

Weiterführende Literatur

• Story-Punkte vs. Stunden – warum die Umrechnung von Punkten in Stunden genau der Fehlerquelle ist, die durch „Velocity“ ersetzt wird.
• Velocity und Kapazitätsplanung – Nutzung der Velocity zur Festlegung eines realistischen Umfangs des Sprints.
• Was ist ein Burndown-Diagramm? – So verfolgen Teams die Punkte, zu deren Umsetzung sie sich innerhalb eines Sprints verpflichtet haben.
• Leitfaden zur agilen Schätzung – der vollständige Schätzungs-Cluster.
• Kostenloses Planning Poker für agile Teams – Schätzen Sie die Punkte, aus denen sich die Velocity zusammensetzt.