Velocity in der Softwareentwicklung: So messen Sie agile Velocity 2026

Yury Pukhov CEO & Leiter Mobile Engineering, YuSMP Group

Velocity (Softwareentwicklung) ist das einfachste Prognosewerkzeug der agilen Arbeit: Sie addieren die Arbeit, die ein Team in einem Sprint fertiggestellt hat, mitteln den Wert über mehrere Sprints und wissen dann ungefähr, wie viel das Team beim nächsten Mal übernehmen kann. Die Idee stammt aus Extreme Programming und ist heute Standard in Scrum und anderen iterativen Frameworks – und zugleich eine der am häufigsten missbrauchten Zahlen im Engineering-Management.

Richtig eingesetzt, macht Velocity aus einem Planungsmeeting ein kurzes, datenbasiertes Gespräch. Problematisch wird es, sobald jemand sie zum Ziel erklärt: Die Schätzungen steigen, und nach ein oder zwei Quartalen sagt die Zahl kaum noch etwas aus. Unternehmen, die ergebnisorientierte Product-Engineering-Services einkaufen, sehen Velocity deshalb meist neben Delivery- und Produktmetriken und nicht allein, denn eine stabile Velocity verrät nicht, ob die gelieferte Arbeit eine geschäftliche Kennzahl bewegt hat.

Im Folgenden finden Sie die Formel mit einem durchgerechneten Beispiel über sechs Sprints, eine Release-Prognose zum Übernehmen, einen Vergleich von Velocity mit Kapazität, Durchsatz und DORA-Metriken sowie die Fehler, die Velocity zu einer Eitelkeitskennzahl machen – einschließlich der neuen, die KI-Coding-Tools 2026 mit sich bringen.

Was ist Velocity in der Softwareentwicklung?

Velocity in der Softwareentwicklung ist die Menge an Arbeit, die ein agiles Team in einer Iteration abschließt, gemessen in denselben relativen Einheiten, mit denen das Team schätzt – meist Story Points (relative Schätzungen von Aufwand, Komplexität und Unsicherheit statt Stunden). Es zählt nur Arbeit, die die Definition of Done des Teams erfüllt, also die gemeinsame Checkliste dafür, wann ein Element wirklich fertig ist. Die Zahl dient dazu, zu prognostizieren, wie viel dasselbe Team in künftigen Iterationen schaffen kann.

Velocity ist ein empirisches Maß: Sie hält fest, was passiert ist, statt vorzugeben, was passieren sollte. Der Wert der Velocity liegt im Trend über mehrere Sprints, nicht in einem einzelnen Sprint. Ein Team, das in seinen letzten drei zweiwöchigen Sprints 30, 34 und 32 Punkte abgeschlossen hat, hat eine Velocity von etwa 32 Punkten pro Sprint – und diese Zahl ist nur für genau dieses Team aussagekräftig, mit seiner Schätzskala, seiner Codebasis und seiner Definition of Done.

Das Konzept entstand Ende der 1990er-Jahre im Extreme Programming: Teams nutzten die in der letzten Iteration erledigte Arbeitsmenge („yesterday’s weather“), um die nächste zu planen. Mike Cohns Buch Agile Estimating and Planning machte Velocity später zusammen mit Story Points populär. Der offizielle Scrum Guide verlangt Velocity überhaupt nicht; er sagt nur, dass bisherige Leistung und Kapazität des Teams in die Auswahl der Arbeit im Sprint Planning einfließen.

Sprint-Velocity vs. Team-Velocity

Sprint-Velocity ist die Zahl der in einem bestimmten Sprint abgeschlossenen Punkte, Team-Velocity dagegen der Durchschnitt über mehrere jüngste Sprints. Die Sprint-Velocity ist ein Datenpunkt, die Team-Velocity die Planungsgröße. Auf Basis eines einzelnen Sprints zu planen ist riskant, weil ein Sprint durch Urlaub, einen Produktionsvorfall oder eine ungewöhnlich große Story, die erst am letzten Tag fertig wird, verzerrt sein kann.

Mit welchen Einheiten lässt sich Velocity messen?

Story Points sind die gebräuchlichste Einheit der Velocity, doch jede konsistente Einheit für abgeschlossene Arbeit ist möglich. Wichtiger als die Wahl selbst ist, dass sie über die Zeit stabil bleibt.

• Story Points: relative Schätzungen von Aufwand, Komplexität und Unsicherheit, oft auf einer Fibonacci-ähnlichen Skala (1, 2, 3, 5, 8, 13).
• Ideale Tage oder Stunden: Schätzungen ungestörten Aufwands, Stakeholdern leichter zu erklären, aber anfälliger dafür, als Zeitzusage verstanden zu werden.
• Anzahl der Elemente: abgeschlossene Stories oder Tickets pro Sprint – funktioniert gut, wenn die Arbeit in ähnlich große Elemente geschnitten ist.
• In Zahlen umgerechnete T-Shirt-Größen: S, M und L werden festen Werten zugeordnet, ein Kompromiss für Teams, die mit dem Schätzen beginnen.

Elemente statt Punkte zu zählen erspart das Schätzritual und verhält sich wie Durchsatz. Das funktioniert allerdings nur, wenn das Team die Arbeit konsequent in kleine, vergleichbare Stücke teilt.

Wie berechnet man die Velocity in der agilen Softwareentwicklung?

Um die Velocity in der agilen Softwareentwicklung zu berechnen, addieren Sie die Story Points aller Elemente, die in einem Sprint die Definition of Done erfüllt haben, und mitteln diese Summe über die letzten drei bis fünf gleich langen Sprints. Die Formel lautet: Velocity = Summe der abgeschlossenen Story Points in den betrachteten Sprints ÷ Anzahl der betrachteten Sprints.

1. Sprintlänge festlegen. Nutzen Sie Iterationen gleicher Dauer, zum Beispiel zwei Wochen, sonst sind Sprints nicht vergleichbar.
2. Nur fertige Arbeit zählen. Ein Element zählt, wenn es die Definition of Done erfüllt: programmiert, reviewt, getestet und abgenommen. Teilweise erledigte Elemente zählen null.
3. Punkte pro Sprint addieren. Summieren Sie die Schätzungen aller abgeschlossenen Elemente; diese Summe ist die Sprint-Velocity.
4. Mehrere Sprints mitteln. Bilden Sie einen gleitenden Durchschnitt der letzten drei bis fünf Sprints, um Ausreißer zu glätten.
5. Eine Spanne statt einer Zahl berichten. Notieren Sie neben dem Durchschnitt den niedrigsten und höchsten jüngsten Wert, denn erst die Streuung macht Prognosen ehrlich.

Die folgende Tabelle zeigt ein durchgerechnetes Beispiel für ein Team aus fünf Engineers mit zweiwöchigen Sprints.

Ein gleitender Durchschnitt der letzten drei Sprints (35, 21 und 33) ergibt eine Velocity von etwa 30 Punkten. Über alle sechs Sprints liegt der Durchschnitt bei 29 Punkten mit einer Spanne von 21 bis 35. Für die Planung sollte dieses Team in einem normalen Sprint mit etwa 29–31 Punkten rechnen und alles über 35 ohne Veränderung im Team oder in der Arbeit als unwahrscheinlich betrachten.

Zählen unfertige Story Points zur Velocity?

Nein, unfertige Story Points zählen nicht zur Velocity. Ist eine Story am Sprintende zu 90 % erledigt, trägt sie in diesem Sprint null Punkte bei; ihre volle Schätzung zählt in dem Sprint, in dem sie fertig wird. Punkte aufzuteilen, um Teilarbeit „anzurechnen“, verdeckt das eigentliche Problem – meist war die Story zu groß oder der Sprint überladen. Übertragene Stories neu zu schätzen ist optional; viele Teams behalten die ursprüngliche Schätzung, um Inflation zu vermeiden.

Sollten Bugs und technische Schulden in die Velocity einfließen?

Bugs und Arbeit an technischen Schulden sollten nur dann in die Velocity einfließen, wenn das Team sie vor dem Sprint genauso in Punkten schätzt wie Stories. Wird ungeplantes Bugfixing ausgeschlossen, sinkt die Velocity bei schlechter Qualität – eine nützliche Information. Entscheidend ist Konsistenz: Legen Sie einmal fest, wie das Team Bugs, Spikes und Wartung behandelt, und halten Sie diese Regel stabil, damit der Trend vergleichbar bleibt.

Was brauchen Sie, um Velocity genau zu messen?

Für eine genaue Messung der Velocity brauchen Sie ein stabiles Team, eine feste Sprintlänge, eine strikte Definition of Done und eine konsistente Schätzpraxis. Ändert sich eine dieser vier Bedingungen, sagt die bisherige Velocity künftige Arbeit nur noch schwach voraus.

• Ein stabiles Team. Wer Personen hinzufügt oder abzieht, verändert die Velocity, oft über mehrere Sprints. Neue Mitglieder bremsen das Team zunächst, während sie sich einarbeiten.
• Konsistente Sprintlänge. Zweiwöchige Sprints lassen sich ohne Normalisierung nicht mit dreiwöchigen vergleichen.
• Eine starke Definition of Done. Bedeutet „fertig“ mal „gemergt“ und mal „released“, driftet die Velocity aus Gründen, die mit dem Output nichts zu tun haben.
• Konsistente Schätzpraxis. Dieselben Referenz-Stories und dieselben schätzenden Personen halten Punkte über die Zeit vergleichbar.
• Ein verlässliches Tracking-Tool. Jira, Azure DevOps, Linear oder ein ähnliches Tool muss Statuswechsel korrekt erfassen, sonst sind die Daten unvollständig.

Schätzt Ihr Team in Stunden oder Tagen statt in Punkten, gilt dieselbe Logik. Unser Leitfaden zur Software-Projektschätzung vergleicht Story Points, Drei-Punkt-Schätzungen und andere Techniken, die in eine velocity-basierte Planung einfließen.

Wie nutzen Teams Velocity in der Sprint- und Release-Planung?

Teams nutzen Velocity als einen Input, um zu entscheiden, wie viel Arbeit in den nächsten Sprint kommt, und um vorherzusagen, wann ein Backlog bekannter Größe abgearbeitet ist. Velocity informiert die Entscheidung, trifft sie aber nicht. Das Team sagt weiterhin auf Basis dessen zu, wer tatsächlich verfügbar ist, was gerade am wichtigsten ist und was in diesem konkreten Sprint schiefgehen könnte.

So leiten Sie ein Sprintziel aus der Velocity ab

Starten Sie im Sprint Planning bei der durchschnittlichen Velocity und passen Sie sie an bekannte Kapazitätsänderungen an. Liegt das Team im Schnitt bei 30 Punkten und fehlt einer von fünf Engineers den halben Sprint, ist ein realistisches Ziel etwa 27 Punkte. Feiertage, Bereitschaftsdienst, Onboarding und geplante Workshops verringern die Kapazität und sollten abgezogen werden, bevor das Team zusagt.

Der Leitfaden zu Scrum in der Softwareentwicklung beschreibt, wie Sprint Planning, Sprint Goal und Sprint Backlog zusammenspielen; Velocity sorgt lediglich dafür, dass der gewählte Umfang innerhalb dessen bleibt, was das Team nachweislich schafft.

Ein Release mit einer Spanne prognostizieren

Für eine Release-Prognose teilen Sie das verbleibende Backlog durch die niedrige und die hohe Velocity des Teams und erhalten so eine Terminspanne statt eines einzelnen Datums. Bei einem Release-Backlog von 240 Punkten und einer Velocity-Spanne von 26 bis 34 Punkten pro Sprint:

1. Optimistischer Fall: 240 ÷ 34 ≈ 7 Sprints.
2. Pessimistischer Fall: 240 ÷ 26 ≈ 9,2, also 10 Sprints.
3. In Kalenderzeit umrechnen: Bei zweiwöchigen Sprints liegt die Prognose bei 14 bis 20 Wochen.

• Puffer für Scope-Wachstum einplanen. Backlogs wachsen während der Umsetzung typischerweise, weil das Team dazulernt; verfolgen Sie Scope-Änderungen separat, damit sie sichtbar bleiben.
• Jeden Sprint neu prognostizieren. Aktualisieren Sie die Spanne mit jedem neuen Datenpunkt, statt die erste Schätzung zu verteidigen.
• Für größere Releases probabilistisch prognostizieren. Eine Monte-Carlo-Simulation, die tausende mögliche Verläufe aus Ihrer historischen Velocity oder Ihrem Durchsatz durchspielt, liefert Aussagen wie „mit 85 % Wahrscheinlichkeit bis Woche 18“ – ehrlicher als ein einzelnes Datum.

Was ist der Unterschied zwischen Velocity, Kapazität, Durchsatz und Produktivität?

Velocity misst abgeschlossene Arbeit pro Sprint, Kapazität die verfügbare Arbeitszeit, Durchsatz die fertigen Elemente pro Zeitraum und Produktivität das Verhältnis von Output zu Wert und Aufwand. Sie beantworten unterschiedliche Fragen und werden leicht verwechselt – was zu schlechten Entscheidungen führt.

Teams mit kontinuierlichem Flow statt Sprints erfassen Velocity selten und stützen sich auf Durchsatz, Cycle Time und WIP-Limits; der Leitfaden zur Kanban-Softwareentwicklung erklärt dieses Modell. Für eine breitere Sicht auf Messung jenseits des Sprints lesen Sie unseren Artikel zur Produktivität in der Softwareentwicklung.

Was beeinflusst die Velocity in der Softwareentwicklung?

Die Velocity in der Softwareentwicklung hängt vor allem von Teamstabilität, Größe der Arbeitselemente, Unterbrechungen, technischen Schulden und der Qualität der Delivery-Pipeline ab – nicht davon, wie hart die Menschen arbeiten. Wer diese Faktoren kennt, kann einen Einbruch erklären, bevor jemand das Team auffordert, „schneller zu werden“.

• Teamzusammensetzung und Wechsel. Neueinstellungen, Abgänge und zwischen Teams geteilte Engineers verändern die Velocity.
• Größe und Klarheit der Stories. Große, vage Stories wandern von Sprint zu Sprint und machen die Velocity sprunghaft.
• Ungeplante Arbeit. Produktionsvorfälle, dringende Supportanfragen und Ad-hoc-Wünsche von Stakeholdern verbrauchen Kapazität.
• Technische Schulden und Codequalität. Fragiler Code, fehlende Tests und komplexe Abhängigkeiten verlangsamen jede Änderung.
• Review- und Deployment-Workflow. Lange Code-Review-Warteschlangen, manuelles Testen und langsame CI-Pipelines verzögern den Moment, in dem Arbeit „fertig“ ist.
• Externe Abhängigkeiten. Warten auf ein anderes Team, eine Dienstleister-API oder eine Sicherheitsfreigabe blockiert sonst fertige Arbeit.
• Work in Progress. Wer viele Elemente gleichzeitig beginnt, verteilt die Aufmerksamkeit und schließt weniger davon ab.

Die Aufgabenkomplexität verdient einen eigenen Blick, denn dieselbe Punktzahl kann sehr unterschiedliche Risiken verbergen. Unser Leitfaden zu Komplexitätsmetriken für Aufgaben in der Softwareentwicklung behandelt kognitive und codebasierte Maße, die erklären, warum manche Sprints stocken.

Agile Velocity vs. Developer Velocity: Was ist der Unterschied?

Agile Velocity ist eine Planungsgröße des Teams in Story Points, während „Developer Velocity“ ein breiterer Managementbegriff dafür ist, wie schnell eine Engineering-Organisation Ideen in funktionierende Software verwandelt. Beide teilen ein Wort, beantworten aber unterschiedliche Fragen.

Der Begriff Developer Velocity wurde durch McKinseys Studie zum Developer Velocity Index aus dem Jahr 2020 bekannt, die starke Engineering-Praktiken wie Tools, Produktmanagement und Kultur mit der Unternehmensleistung verknüpfte. Laut der McKinsey-Studie wuchsen Unternehmen im obersten Quartil des Index beim Umsatz vier- bis fünfmal schneller als jene im untersten Quartil. Developer Velocity in diesem Sinne betrifft Fähigkeiten und Umfeld, nicht Sprint-Punkte.

Für die organisationsweite Delivery-Performance nutzen die meisten Teams 2026 die DORA-Metriken des DevOps-Research-and-Assessment-Programms von Google: Deployment-Frequenz, Lead Time for Changes, Change Failure Rate und Time to Restore Service. Flow-Metriken wie Cycle Time und Work in Progress vervollständigen das Bild. Velocity kann als Planungshilfe des Teams danebenstehen, sollte sie aber nicht ersetzen. Unsere Liste der KPIs in der Softwareentwicklung zeigt, wie diese Metriken zusammenpassen.

Welches sind die häufigsten Fehler im Umgang mit Velocity?

Der häufigste Fehler ist, Velocity als Leistungsziel zu behandeln – das bläht die Schätzungen schnell auf und zerstört ihren Wert für die Planung. Goodharts Gesetz beschreibt den Effekt treffend: Wird eine Messgröße zum Ziel, hört sie auf, eine gute Messgröße zu sein.

• Velocity zwischen Teams vergleichen. Jedes Team hat seine eigene Punkteskala; 40 Punkte im einen und 20 im anderen Team sagen nichts darüber, wer mehr liefert.
• Velocity-Ziele setzen. Die Forderung nach „10 % mehr Punkten im nächsten Quartal“ erzeugt vor allem größere Schätzungen, nicht mehr gelieferten Wert.
• Velocity in individuellen Leistungsbeurteilungen verwenden. Velocity ist eine Teammetrik; sie pro Person aufzuteilen fördert lokale Optimierung und hält von Pairing und Code-Reviews ab.
• Teilweise erledigte Arbeit zählen. Wer unfertige Stories anrechnet, lässt die Velocity stabil aussehen, obwohl die Lieferung es nicht ist.
• Qualität ignorieren. Steigende Velocity bei mehr entwischten Fehlern oder fehlgeschlagenen Deployments bedeutet meist, dass das Team Abkürzungen nimmt.
• Mit maximaler Velocity planen. Wer sich am besten Sprint aller Zeiten orientiert, lässt keinen Raum für ungeplante Arbeit und lässt die meisten Sprints wie Misserfolge aussehen.
• Story Points stillschweigend neu kalibrieren. Referenz-Stories zu ändern, ohne die Velocity-Historie zurückzusetzen, zerstört die Vergleichbarkeit.

Wie lässt sich die Velocity verbessern, ohne Story Points zu manipulieren?

Nachhaltig verbessern Sie die Velocity, indem Sie Reibung aus dem Delivery-System entfernen – zu große Stories, Wartezeiten und Nacharbeit –, statt Menschen zu mehr Punkten zu drängen. Echte Verbesserung zeigt sich als höhere oder stabilere Velocity bei gleichbleibender Qualität und kürzerer Cycle Time.

1. Stories kleiner schneiden. Elemente, die in zwei oder drei Tage passen, wandern selten in den nächsten Sprint und machen die Velocity berechenbarer.
2. Work in Progress begrenzen. Erst abschließen, dann Neues beginnen – das reduziert Kontextwechsel und halbfertige Elemente am Sprintende.
3. Code-Review- und CI-Zeiten verkürzen. Reviews innerhalb eines Arbeitstags und eine schnelle, zuverlässige Pipeline verkürzen den Weg zu „fertig“.
4. In automatisierte Tests investieren. Eine solide Testsuite reduziert manuelle Regressionstests und die Nacharbeit nach entwischten Fehlern.
5. Technische Schulden gezielt abbauen. Reservieren Sie einen festen Anteil jedes Sprints für Schulden in den Bereichen, die das Team am stärksten bremsen.
6. Das Team vor ungeplanter Arbeit schützen. Leiten Sie Support und dringende Anfragen über eine rotierende Person, statt alle zu unterbrechen.
7. Retrospektiven mit echten Daten führen. Betrachten Sie Übertrag, blockierte Zeit und Cycle Time, wählen Sie pro Sprint eine Verbesserung und prüfen Sie, ob sie gewirkt hat.

Wie verändern KI-Coding-Tools die Velocity 2026?

KI-Coding-Assistenten können die Menge des produzierten Codes erhöhen, machen Velocity 2026 aber schwerer interpretierbar, weil schnelleres Programmieren nicht automatisch schnellere Lieferung funktionierender Software bedeutet. Teams sollten bei der Einführung von KI-Tools Qualitäts- und Stabilitätsmetriken neben der Velocity beobachten.

Der DORA-Bericht 2025 zur KI-gestützten Softwareentwicklung ergab, dass rund 90 % der befragten Technologie-Fachleute KI bei der Arbeit nutzen und dass die KI-Nutzung inzwischen positiv mit dem Delivery-Durchsatz zusammenhängt. Dieselbe Studie zeigte, dass KI-Nutzung weiterhin mit höherer Delivery-Instabilität korreliert, also mit mehr fehlgeschlagenen Änderungen und Nacharbeit. DORA beschreibt KI als Verstärker: Sie stärkt gute Engineering-Systeme und legt schwache offen.

• Schätzungen neu kalibrieren. Werden Routineaufgaben mit KI schneller, müssen Referenz-Stories eventuell neu geschätzt werden; setzen Sie dann die Velocity-Basis zurück.
• Die Review-Last beobachten. Mehr generierter Code verlagert den Engpass oft zu Code-Review und Tests, was die echte Velocity begrenzt.
• Die Change Failure Rate verfolgen. Ein Velocity-Anstieg bei steigender Change Failure Rate ist keine Verbesserung.

Was verrät die Velocity über ein ausgelagertes Entwicklungsteam?

Velocity zeigt Ihnen, ob ein ausgelagertes Team berechenbar ist – nicht, ob es produktiv ist oder sein Geld wert. Eine stabile Velocity mit ehrlichen Release-Spannen ist ein gutes Zeichen; eine Velocity, die nur steigt, deutet meist auf Inflation hin.

Wenn Sie mit einem externen oder dedizierten Entwicklungsteam arbeiten, stellen Sie vier einfache Fragen: Wie schätzen Sie, was umfasst Ihre Definition of Done, was passiert mit Übertrag, und wie prognostizieren Sie ein Release? Lassen Sie sich dann die Velocity neben Cycle Time, entwischten Fehlern und Deployment-Frequenz zeigen. Ein Partner, der nur Story Points berichtet oder eine feste Velocity verspricht, bevor er Ihre Codebasis kennt, verkauft eine Zahl statt eines Delivery-Prozesses.

Häufig gestellte Fragen