Team-Velocity im agilen Entwicklungsansatz: So messen und nutzen Sie sie (+ kostenloser Rechner)

Die Team-Velocity ist eine Grundlage für Prognosen, kein KPI. Sobald Sie Teams daran messen, wird sie künstlich aufgebläht.

Die Velocity ist die durchschnittliche Anzahl an Story-Punkten, die ein Team pro Sprint absolviert, berechnet über die letzten Sprints. Das ist die gesamte Definition. Sie dient einem einzigen Zweck: der Prognose, wie viele Sprints die Fertigstellung 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 Anwendung führt zu Fehlinterpretationen. Die Frage „Warum war die Velocity in diesem Sprint niedriger?“ verwandelt jede Retrospektive in eine Rechtfertigung der Zahl. Die Aussage „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 tun, indem es denselben Arbeitsumfang größer auswertet, anstatt mehr davon zu erledigen. Das ist Goodharts Gesetz im Zwei-Wochen-Zyklus.

Eine ehrliche Vorbemerkung vor der Anleitung: Die Scrum-Leitfaden Es wird nicht auf die Geschwindigkeit eingegangen. Es handelt sich um eine gängige Praxis, die auf Scrum aufbaut, jedoch keine Regel desselben darstellt – und genau deshalb lohnt es sich, bewusst zu überlegen, wofür Sie sie einsetzen.

So berechnen Sie die Team-Velocity

Nehmen Sie die in jedem der letzten drei bis fünf Sprints erreichten Punkte. Berechnen Sie den Durchschnitt daraus. Das ist Ihre Geschwindigkeit.

Ein Beispiel über drei Sprints hinweg:

Sprint	Abgeschlossene Story-Punkte
Sprint 7	21
Sprint 8	34
Sprint 9	26

Geschwindigkeit = (21 + 34 + 26) geteilt durch 3 = 27 Punkte pro Sprint.

Wenn der Backlog noch 210 Punkte umfasst, ergibt sich aus der Prognose 210 geteilt durch 27 ein Wert von etwa 8 Sprints. Da die Eingabewerte zwischen 21 und 34 lagen, lautet die ehrliche Angabe „sieben bis zehn Sprints“ und nicht „7,8 Sprints“. Oder überspringen Sie die Berechnung und lassen Sie den obigen Rechner die Berechnung für Sie durchführen.

Die Regeln, die für ehrliche Zahlen sorgen: Nehmen Sie keine Anpassungen für „außergewöhnliche“ Sprints vor, da diese außergewöhnlichen Sprints Teil des Signals sind, das Sie glätten möchten. Zählen Sie übertragene Arbeit nicht doppelt und berücksichtigen Sie teilweise abgeschlossene Stories überhaupt nicht. Diese werden erst im Sprint gezählt, in dem sie tatsächlich abgeschlossen 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 oder eine größere personelle Veränderung sind allesamt 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.

Nutzung der Velocity zur Planung des nächsten Sprints

Velocity bewährt sich bei der Planung des Sprints, und die Methode lässt sich kurz zusammenfassen:

1. Gehen Sie vom gleitenden Durchschnitt der letzten drei bis fünf Sprints aus, niemals vom Wert eines einzelnen Sprints und niemals von Ihrem besten Sprint.
2. Berücksichtigen Sie bekannte Kapazitätsänderungen. Sind im nächsten Sprint zwei Mitarbeiter im Urlaub? Steht ein Feiertag an? Passen Sie das Ziel vor der Planung proportional nach unten an, anstatt sich hinterher entschuldigen zu müssen. Die Velocity basiert auf dem Team, das sie erzielt hat, und das Team des nächsten Sprints ist manchmal kleiner.
3. Legen Sie sich unter dem Durchschnitt fest, etwa bei 80 bis 90 Prozent davon. Wählen Sie Aufgaben so aus, dass sich deren Gesamtumfang in etwa auf diesen Wert beläuft, und lassen Sie Slack für die ungeplanten Arbeiten, die in jedem Sprint anfallen – unabhängig davon, ob Sie diese einkalkuliert haben oder nicht.
4. Geben Sie Prognosen in Spannen an. Für alles, was über den nächsten Sprint hinausgeht, geben Sie Ihren besten und Ihren schlechtesten Sprint der letzten Zeit als Ober- und Untergrenze an. Die Beteiligten können auf der Grundlage von „sieben bis zehn Sprints“ planen. Sie können nicht auf der Grundlage einer genauen Zahl planen, die sich später als falsch herausstellt.

Nutzen Sie die Velocity für drei Dinge – und nur für diese drei: um ein Datum für einen bekannten Umfang zu prognostizieren (der Umfang geteilt durch die Velocity ergibt die Anzahl der Sprints), um zu entscheiden, was in den nächsten Sprint passt, und um festzustellen, wann sich etwas geändert hat (ein Rückgang um 30 Prozent ist ein Signal, das eine Retrospektive rechtfertigt). Was Sie damit nicht tun dürfen: 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.

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 werden anhand der Referenz-Story des Teams kalibriert.

Der große Fehler: Geschwindigkeit als Leistungskennzahl

Die mit Abstand häufigste Fehlerquelle: Ein Manager interpretiert einen Velocity-Wert als Maßstab 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 damit eigentlich erstellt werden sollte, ist nun falsch.

Zweitens: Der Vergleich von Teams. Zwei Teams, die denselben Backlog 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. Die Zahlen haben nicht dieselbe Aussagekraft, und wenn man sie so behandelt, als ob dies der Fall wäre, wird die Kalibrierung beider Teams verfälscht.

Möchten Sie, dass die Berechnungen für Sie übernommen werden? Kehren Sie zum kostenlosen Geschwindigkeitsrechner zurück und geben Sie dort Ihre eigenen Sprintdaten ein.

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 jedoch 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 Rate, 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, das darauf hinweist, 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 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 wirklich.

Durch die 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 deren Velocities addiert werden können. Die Methode funktioniert: Eine normalisierte 5 hat tatsächlich für alle Teams, die sich darauf geeinigt haben, dieselbe Bedeutung. Das Problem ist jedoch, was Sie dafür eingetauscht 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 eine gemeinsame Domäne haben.

Wenn eine Prognose auf Portfolioebene tatsächlich der Finanzierung der Arbeit dient (und nicht nur dem Vergleich der Teams), führen Sie die Normalisierung auf der Zusammenfassungsebene 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. Was Sie ablehnen sollten: eine Normalisierung, die innerhalb eines einzelnen Teams beginnt, sowie eine Normalisierung, die durchgeführt wird, um den Vergleich zwischen Teams zu erleichtern. Letzteres ist kein Anwendungsfall, sondern ein Anti-Muster mit einem geschliffenen Namen.

Velocity und KI-Entwicklungstools

Copilot, Cursor, Claude Code. Die Punkte ändern sich nicht. Die Geschwindigkeit ändert sich, und zwar 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 aus der 3 des letzten Quartals eine 5 für dieses Quartal werden? Die Antwort lautet „nein“, denn Story-Points haben nie das gemessen, was sich tatsächlich geändert hat. Story-Punkte messen relative Komplexität und Unsicherheit; der Assistent reduziert zwar den Zeitaufwand für die Programmierung einer 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, schätzen Sie wieder in Stunden.

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 Kennzahl, 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 Referenz-Story 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“ – damit wird die Verbesserung doppelt gezählt: Der aktuelle Durchschnitt beinhaltet bereits den KI-Effekt, daher sollten Sie diesen 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.

Gemeinsame Schätzung in TeamRetro

Die Genauigkeit von Velocity hängt vollständig von der Qualität der zugrunde liegenden Schätzungen ab. TeamRetro Estimations führt mit Ihrem Team ein Planning-Poker-Spiel durch – entweder live oder asynchron –, sodass die Punkte, die Sie in diesen Rechner eingeben, auf der Einschätzung des gesamten Teams beruhen und nicht auf der Vermutung einer einzelnen Person. Probieren Sie TeamRetro Estimations aus oder beginnen Sie mit dem kostenlosen Planning-Poker-Tool.

Häufig gestellte Fragen

Was versteht man unter Team-Velocity im agilen Entwicklungsansatz?

Die Team-Velocity ist die durchschnittliche Anzahl an Story-Punkten, die ein Team pro Sprint abarbeitet; sie wird in der Regel über die letzten drei bis fünf Sprints gemessen. Sie dient als Planungsgrundlage, um abzuschätzen, wie viel in den nächsten Sprint passt und wie lange die Bearbeitung des Backlogs dauern wird – sie ist kein Maßstab für die Leistungsfähigkeit des Teams.

Wie berechnet man die Team-Velocity?

Addieren Sie die in jedem der letzten drei bis fünf Sprints abgeschlossenen Story-Punkte und berechnen Sie den Durchschnitt. Wenn Sie in Ihren letzten drei Sprints 21, 34 und 26 Punkte abgeschlossen haben, beträgt Ihre Velocity 27. Berücksichtigen Sie dabei nur abgeschlossene Stories in dem Sprint, in dem sie fertiggestellt wurden, oder nutzen Sie den kostenlosen Rechner auf dieser Seite, um die Zahlen zu berechnen.

Was ist eine gute Team-Velocity?

Eine stabile Velocity. Es gibt keinen Maßstab, da die Punkte jedes Teams auf seine eigene Referenzgeschichte abgestimmt sind; daher können sowohl 15 als auch 40 und 100 als gut angesehen werden. Eine gute Velocity ist eine, auf deren Grundlage Sie planen können – und nicht eine Zahl, die ständig weiter steigt.

Sollten Sie die Arbeitsgeschwindigkeit der verschiedenen Teams miteinander vergleichen?

Nein. Verschiedene Teams kalibrieren ihre Punkte anhand unterschiedlicher Referenzgeschichten, sodass ihre Velocities nicht in denselben Einheiten angegeben sind. Ein Vergleich dieser Werte ist vergleichbar mit dem Vergleich zweier Thermometer mit unterschiedlichen Nullpunkten. Ein teamübergreifender Vergleich setzt die Teams zudem unter Druck, ihre Schätzungen zu überhöhen, was die Prognosen verfälscht, zu deren Erstellung die Velocity eigentlich dient.

Was wäre, wenn wir nicht in Punkten schätzen würden, sondern beispielsweise T-Shirt-Größen verwenden würden?

Sie können zwar weiterhin einen ungefähren Durchsatz erfassen, jedoch lässt sich aus den T-Shirt-Größen kein genauer Wert für die Velocity ableiten, da sich die Größen nicht addieren lassen. Es gibt zwei Möglichkeiten. Ordnen Sie die Größen zunächst einer einfachen Punkteskala zu (zum Beispiel XS=1, S=2, M=3, L=5, XL=8), summieren Sie die fertiggestellten Elemente pro Sprint und betrachten Sie das Ergebnis eher als groben Trend denn als präzisen Wert. Oder, falls Ihre Aufgaben in der Regel einen ähnlichen Umfang haben, zählen Sie stattdessen den Durchsatz: die Anzahl der pro Sprint abgeschlossenen Aufgaben. Beide Methoden sind ungenauer als die punktebasierte Velocity; betrachten Sie sie daher als Richtwert und nicht als Dezimalwerte. Wenn Sie eine echte Prognose benötigen, schätzen Sie den kurzfristigen Arbeitsaufwand erneut in Punkten ein. In unserem Leitfaden zur T-Shirt-Größenbestimmung finden Sie eine Übersicht über die Umrechnung von Größen in Punkte.

Wie erfassen wir Arbeiten, die nicht als bemessene Posten erfasst sind?

Die Velocity spiegelt nur die Arbeit wider, die Sie tatsächlich quantifizieren und nachverfolgen. Support-Tickets, Besprechungen, Unterbrechungen und nicht zugeordnete Fehlerbehebungen beanspruchen dennoch Kapazität. Wenn also ein Großteil dieser Arbeit unsichtbar bleibt, wird Ihre Velocity niedriger ausfallen als der tatsächliche Aufwand des Teams, und Ihre Prognosen werden zu optimistisch ausfallen. Zwei sinnvolle Lösungsansätze. Erfassen Sie die wiederkehrende, ungeplante Arbeit als bewertete Elemente, damit sie wie alles andere in die Velocity einfließt. Oder reservieren Sie offen Kapazität dafür, indem Sie sich auf etwa 80 bis 90 Prozent Ihres Durchschnitts festlegen und den Rest als Slack belassen. Weisen Sie unsichtbarer Arbeit keine Punkte nachträglich zu, nur um die Zahl größer erscheinen zu lassen, denn das stört die Kalibrierung, auf der die Velocity beruht.

Wie gehen Sie bei Velocity mit Nacharbeiten um?

Nacharbeit ist zwar mit echtem Aufwand verbunden, doch das erneute Einplanen einer Story, die bereits als erledigt gezählt wurde, beeinträchtigt die Velocity. Behandeln Sie Nacharbeit wie neue Arbeit: Erstellen Sie ein neues Element, schätzen Sie dessen Umfang und zählen Sie es in dem Sprint, in dem es fertiggestellt wird. Öffnen Sie die ursprüngliche Story nicht erneut und schätzen Sie sie nicht neu ein. Wenn immer wieder Nacharbeiten auftreten, ist dies ein Qualitätssignal, das eine Diskussion im Rahmen der Retrospektive rechtfertigt – und keine Anpassung der Velocity. Die Prognose bleibt nur dann zuverlässig, wenn jeder Punkt nur einmal gezählt wird, und zwar im Sprint, in dem die Arbeit tatsächlich abgeschlossen wurde.

Wie viele Story-Punkte pro Sprint sind üblich?

Es gibt keinen branchenüblichen Richtwert. Die Velocity ist der gemessene Durchsatz Ihres Teams, also 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 Referenz-Story 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 individueller 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, aber legen Sie es nicht als Ziel fest. Wählen Sie Stories so aus, dass sie insgesamt etwa 80 bis 90 Prozent Ihres jüngsten Durchschnitts ausmachen, und lassen Sie Spielraum für Unvorhergesehenes.

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

Ein stabiler Wert. „Ist unsere Durchlaufgeschwindigkeit gut?“ – diese Frage bringt das System zum Einsturz. Sobald die Durchlaufgeschwindigkeit bewertet wird, steigen die Punktzahlen in die Höhe, und nichts wird tatsächlich schneller ausgeliefert. Eine gute Durchlaufgeschwindigkeit 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.
• Agile Schätzverfahren: Wie lässt sich die Velocity in den Kontext von Planning Poker, Story Points und den übrigen Methoden einordnen, und wann sollte welches Verfahren zum Einsatz kommen?
• 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.