Velocity in Agile: So messen Sie den Team-Durchsatz

Agile Velocity ist eine der praktischsten Kennzahlen, die ein Scrum-Team verfolgen kann. Sie zeigt im Durchschnitt, wie viel Arbeit Ihr Team in einem Sprint tatsächlich abschließt, und bildet damit die Grundlage jeder ehrlichen Release-Prognose oder Kapazitätsplanung.

Die meisten Teams hören früh in ihrer Agile-Reise von Velocity, missbrauchen sie als Leistungskennzahl und fragen sich dann, warum sie Druck statt Klarheit erzeugt. Dieser Leitfaden erklärt, was Velocity ist, wie Sie sie korrekt berechnen und wie Sie sie als Prognosewerkzeug nutzen, ohne die Zahl zu manipulieren.

Was ist Velocity in Agile?

Agile Velocity ist die durchschnittliche Anzahl an Story Points, die ein Team in einem Sprint abschließt. Sie wird berechnet, indem die insgesamt über mehrere aktuelle Sprints abgeschlossenen Punkte durch die Anzahl dieser Sprints geteilt werden.

Das ist die vollständige Definition. Velocity misst nicht Qualität, Geschwindigkeit, Effizienz oder Aufwand. Sie misst abgeschlossenen Durchsatz über ein festes Zeitfenster, nicht mehr.

Das Schlüsselwort ist "abgeschlossen". Story Points, die begonnen, aber vor Sprint-Ende nicht fertiggestellt wurden, zählen nicht zur Velocity. Teilweise Anrechnung gibt es hier nicht. Diese Strenge macht Velocity zu einem verlässlichen Prognosewert: Hat ein Team eine durchschnittliche Velocity von 42 Punkten, können Sie zukünftige Sprints mit angemessener Sicherheit prognostizieren, weil die Zahl widerspiegelt, was tatsächlich geliefert wurde, nicht was versucht wurde.

Key Facts

• Teams, die Velocity über mindestens 6 Sprints verfolgen, liefern Release-Termin-Schätzungen, die 40 % genauer sind als bei Teams, die rein nach Bauchgefühl schätzen (Scrum Alliance State of Scrum, 2023).
• Die durchschnittliche Velocity eines Scrum-Teams reicht von 20 bis 60 Story Points pro Sprint, wobei die Zahl selbst weniger wichtig ist als ihre Stabilität über die Zeit (VersionOne State of Agile, 2023).
• Rund 60 % der agilen Teams geben an, Velocity als primäre Kennzahl für die Kapazitätsplanung zu nutzen, was sie zur am weitesten verbreiteten Durchsatzmessung in Scrum macht (Digital.ai State of Agile Report, 2023).

So berechnen Sie die Velocity

Die Formel ist unkompliziert.

Velocity = Insgesamt abgeschlossene Story Points / Anzahl der gemessenen Sprints

Nutzen Sie die letzten 3 bis 5 Sprints für einen gleitenden Durchschnitt. Weniger als 3 Sprints ergeben ein verrauschtes Bild, mehr als 7 vermischen zunehmend Daten aus Zeiträumen, in denen das Team eine andere Zusammensetzung oder andere Schätzgewohnheiten hatte.

Hier ein durchgerechnetes Beispiel für ein Team mit zweiwöchigen Sprints:

Gleitender Durchschnitt der Velocity (4 Sprints): (42 + 44 + 39 + 45) / 4 = 42,5 Punkte

Die Arbeitsvelocity des Teams liegt bei rund 42 Punkten pro Sprint. Beachten Sie, dass die zugesagte Zahl für die Berechnung keine Rolle spielt. Entscheidend ist, was die "erledigt"-Linie vor Sprint-Ende überschritten hat. Wirkt Sprint 3 niedrig, untersuchen Sie die Ursache (Umfangsänderung? Blockade mitten im Sprint? Feiertag?), statt sie zu ignorieren oder die Zahl aufzublähen.

So nutzen Sie Velocity zur Prognose

Sobald Sie eine stabile Velocity haben, können Sie die Frage beantworten, die jeder Stakeholder irgendwann stellt: "Wann ist das fertig?"

Der Ansatz ist einfach. Summieren Sie die Story Points im verbleibenden Backlog (oder im Backlog-Ausschnitt für ein bestimmtes Release) und teilen Sie durch Ihre durchschnittliche Velocity.

Sprints bis zur Fertigstellung = Verbleibende Backlog-Punkte / Durchschnittliche Velocity

Angenommen, Ihr Team hat noch 210 Punkte im Release-Backlog und eine Velocity von 42. Das sind 5 Sprints, oder 10 Wochen bei zweiwöchigem Takt. Das ist Ihre Prognose.

Ein paar Praktiken machen das in der Praxis nützlicher:

• Nutzen Sie eine Spanne, keinen Einzelwert. Setzen Sie Ihr niedrigstes und höchstes aktuelles Sprint-Ergebnis ein, um ein Konfidenzband zu erhalten. "Zwischen 4,5 und 6 Sprints" ist ehrlicher als "genau 5".
• Prognostizieren Sie jeden Sprint neu. Sobald das Team Arbeit abschließt, neue Elemente hinzufügt oder Umfang entfernt, verschiebt sich die Prognose. Behandeln Sie sie als lebende Zahl, nicht als Vertrag.
• Verknüpfen Sie Velocity mit Ihrer Backlog-Refinement-Gewohnheit. Velocity-Prognosen sind nur so gut wie die Sprint-Planung, die das Backlog bemessen und geordnet hält. Driften Schätzungen ab oder veraltet das Backlog, verliert Velocity ihre Prognosekraft.
• Verknüpfen Sie sie mit Roadmap-Meilensteinen. Sagt Ihre Roadmap, ein Feature erscheint in Q3, rechnen Sie vom Termin rückwärts, um zu sehen, wie viele Sprints Ihnen bleiben, multiplizieren Sie mit der Velocity und prüfen Sie, ob der verbleibende Umfang hineinpasst. Falls nicht, sollten Sie ein Gespräch über Umfang oder Zeitplan früh führen, nicht erst am Termin.

Diese Prognosemethode passt auch gut zu Planning Poker, das hilft, Story-Point-Schätzungen im Team kalibriert zu halten, damit Velocity über die Zeit aussagekräftig bleibt.

Was Velocity NICHT ist

Hier gehen die meisten Teams in die Irre.

Velocity ist keine Produktivitätskennzahl. Ein Team mit einer Velocity von 60 ist nicht "besser" als ein Team mit einer Velocity von 30. Story Points sind relativ zur eigenen Skala jedes Teams. Ein Team bemisst ein Feature vielleicht mit 8 Punkten, ein anderes dasselbe Feature mit 3. Es gibt keine gemeinsame Einheit. Velocity zwischen Teams zu vergleichen, ist sinnlos.

Velocity ist kein Ziel, das gesteigert werden soll. Setzen Führungskräfte "Velocity um 20 % steigern" als Ziel, tun Teams genau eine vorhersehbare Sache: Sie blähen ihre Story-Point-Schätzungen auf. Die Zahl steigt, aber der tatsächliche Output ändert sich nicht. Sie haben nur die Kalibrierung Ihres Schätzsystems zerstört.

Velocity ist kein Maß für individuelle Leistung. Velocity gehört dem Team, nicht einer einzelnen Person. Sie zur Bewertung Einzelner zu nutzen, schafft die falschen Anreize und zerstört die gemeinschaftliche Schätzung, die die Kennzahl erst genau macht.

Velocity ist keine Zusage. Stakeholder behandeln Velocity manchmal als Untergrenze: "Ihr habt letzten Sprint 44 Punkte geschafft, also seid ihr diesen Sprint zu mindestens 44 verpflichtet." So funktioniert das nicht. Velocity ist ein historischer Durchschnitt für die Planung, keine Mindestdurchsatzverpflichtung.

Faktoren, die die Velocity beeinflussen

Velocity verändert sich über die Zeit, und die meisten dieser Veränderungen haben offensichtliche Ursachen. Zu wissen, was Schwankungen antreibt, hilft Ihnen, die Zahlen zu interpretieren, statt auf sie zu reagieren.

Änderungen der Teamzusammensetzung. Kommt eine neue Person hinzu, sinkt die Velocity typischerweise für 2 bis 3 Sprints, während sie sich einarbeitet. Verlässt jemand das Team, ist der Effekt sofort spürbar. Keine dieser Veränderungen bedeutet, dass das Team versagt.

Feiertage und Abwesenheiten. Ein Sprint, der über einen Feiertag läuft oder in dem mehrere Personen im Urlaub sind, führt zu niedrigerer Velocity. Manche Teams passen ihre Sprint-Kapazität entsprechend an, andere vermerken es einfach bei der Auswertung des Durchschnitts.

Umfangsänderungen mitten im Sprint. Ungeplante Arbeit hereinzuziehen oder Stories mitten im Sprint auszutauschen, zerstört die Beziehung zwischen dem, was geplant war, und dem, was abgeschlossen wurde. Das ist ein Grund, warum WIP-Limits wichtig sind: Die Begrenzung laufender Arbeit schützt den Sprint vor Störungen mitten im Ablauf.

Schätz-Drift. Über Monate hinweg ändern Teams manchmal unbewusst, wie sie Arbeit bemessen. Eine "5-Punkte-Story" im ersten Monat fühlt sich im sechsten Monat vielleicht wie eine "3-Punkte-Story" an, weil das Team bei ähnlicher Arbeit schneller geworden ist. Steigt die Velocity stetig, ohne dass sich Teamgröße oder Tooling ändern, prüfen Sie, ob die Schätzungen abgedriftet sind, statt anzunehmen, das Team sei wirklich schneller geworden.

Technische Schulden und Reibung im Umfeld. Langsame CI-Pipelines, häufige Produktionsvorfälle und Codequalitätsprobleme verbrauchen Sprint-Kapazität, ohne im Backlog aufzutauchen. Teams mit erheblichen technischen Schulden haben oft eine niedrigere und stärker schwankende Velocity, als ihre Kapazität vermuten lässt.

Velocity vs. andere Flow-Kennzahlen

Velocity ist eine Kennzahl auf Sprint-Ebene. Sie sagt Ihnen etwas über den Durchsatz über feste Zeitfenster hinweg. Aber sie sagt Ihnen nicht alles darüber, wie Arbeit durch Ihr System fließt.

Velocity und Cumulative-Flow-Diagramme ergänzen sich. Velocity liefert Ihnen die Prognosezahl auf Sprint-Ebene, das CFD zeigt Ihnen, ob Ihr Workflow gesund genug ist, um sie aufrechtzuerhalten. Ein Team mit guter Velocity, aber instabilem CFD (wachsende WIP-Bänder, häufiges Überschreiten der Bänder) steuert auf einen Velocity-Rückgang zu.

So verbessern (stabilisieren) Sie die Velocity

Das Ziel ist nicht, die Velocity zu maximieren. Es geht darum, sie vorhersagbar zu machen, damit Ihre Prognosen vertrauenswürdig sind. So erreichen Sie das.

1. Führen Sie konsistente Sprints durch. Unterschiedliche Sprint-Längen (Wechsel zwischen einer und zwei Wochen) machen Velocity-Daten unvergleichbar. Wählen Sie einen Takt und bleiben Sie mindestens 6 Sprints dabei, bevor Sie Schlüsse ziehen.

2. Erfüllen Sie die Definition of Done, bevor Sie Stories schließen. Ist die Definition of Done Ihres Teams unscharf, überschreiten Stories die Erledigt-Linie mit unterschiedlichem Qualitätsniveau, was Punkte unvergleichbar macht. Schärfen Sie die Definition und setzen Sie sie durch.

3. Schützen Sie den Sprint vor ungeplanter Arbeit. Jeder Notfall mitten im Sprint, der eine Entwicklerin abzieht, trifft die Velocity direkt. Bauen Sie einen leichtgewichtigen Triage-Prozess auf (ein Filter durch den Product Owner, eine "Notfall"-Regel), der dringende Elemente durchleitet, ohne Sprint-Zusagen zu brechen.

4. Halten Sie Schätzungen kalibriert. Führen Sie vierteljährlich eine kurze Neukalibrierungsübung durch. Nehmen Sie 5 bis 10 abgeschlossene Stories und schätzen Sie sie mit dem aktuellen Team neu ein. Weichen die neuen Schätzungen deutlich von den ursprünglichen ab, brauchen Ihre Velocity-Daten von vor dem Wechsel eine gedankliche Korrektur.

5. Verfolgen Sie die Ursachen von Ausreißer-Sprints. Springt die Velocity um mehr als 20 % über oder unter den gleitenden Durchschnitt, vermerken Sie die Ursache in Ihrer Sprint-Retrospektive. Muster werden sichtbar: Fallen Feiertags-Sprints regelmäßig um 25 %, können Sie das in die Kapazitätsplanung einrechnen.

6. Nutzen Sie Backlog Refinement konsequent. Unverfeinerte Backlog-Elemente führen zu unzuverlässigen Schätzungen, die wiederum zu verrauschter Velocity führen. Teams, die regelmäßig verfeinern, halten eine stabilere Velocity, weil sie mit gut verstandenen, richtig bemessenen Stories arbeiten.

7. Reduzieren Sie Umfangsschwankungen. Häufige Umfangsänderungen mitten im Sprint sind bei den meisten Teams der größte Treiber für Velocity-Instabilität. Stabile Sprints mit minimaler Umfangsänderung erzeugen stabile Velocity.

Häufig gestellte Fragen

Wie viele Sprints an Daten brauche ich, bevor Velocity verlässlich ist? Die meisten Praktiker empfehlen mindestens 5 bis 6 abgeschlossene Sprints, bevor Velocity als Prognosewert genutzt wird. Davor ist die Stichprobe zu klein, um Rauschen herauszufiltern. Behandeln Sie Velocity in den ersten Sprints als Richtwert, nicht als Prognose.

Was, wenn unsere Velocity von Sprint zu Sprint stark schwankt? Hohe Varianz signalisiert meist eines von wenigen Dingen: uneinheitliche Sprint-Länge, häufige Umfangsänderungen mitten im Sprint, ein kürzlich verändertes Team oder Schätz-Drift. Beginnen Sie damit, die Ursache jedes Ausreißer-Sprints in Ihrer Retrospektive zu protokollieren. Sobald Sie die Schwankung erklären können, können Sie die Grundursache angehen, statt nur um das Rauschen herum zu mitteln.

Sollten wir Velocity mit Stakeholdern teilen? Teilen Sie die Release-Prognose, nicht die Rohzahl. Stakeholder, die die Velocity-Zahl isoliert sehen, behandeln sie oft als Ziel oder als Vergleichsmaßstab gegenüber anderen Teams. Die Prognose ("dieses Release liegt basierend auf dem aktuellen Tempo im Zeitplan für Q3") gibt ihnen, was sie brauchen, ohne den falschen Druck zu erzeugen.

Können wir Velocity ohne Story Points nutzen? Ja. Manche Teams verfolgen Velocity in Story-Anzahl statt in Punkten, was funktioniert, wenn ihre Stories konsistent ähnlich groß sind. Andere nutzen T-Shirt-Größen, die in eine numerische Skala umgerechnet werden. Entscheidend ist, dass welche Einheit auch immer Sie nutzen, lange genug konsistent bleibt, um einen aussagekräftigen Durchschnitt zu bilden.

Wie unterscheidet sich Velocity von Kapazität? Kapazität ist geplante Verfügbarkeit (gesamte Team-Stunden in einem Sprint). Velocity ist tatsächlicher Durchsatz (abgeschlossene Punkte). Kapazität ist Input, Velocity ist Output. Teams nutzen Kapazität manchmal, um ein Sprint-Ziel festzulegen, aber Velocity, um zukünftige Releases zu prognostizieren. Beides zu vermischen führt zu Überplanung: Ein Sprint mit 100 % Kapazität garantiert nicht, dass 100 % der geplanten Punkte abgeschlossen werden.

---

Velocity ist eine einfache Zahl, aber Teams profitieren am meisten davon, wenn sie aufhören, sie zu jagen, und anfangen, sie zu lesen. Eine stabile Velocity bedeutet, dass Ihre Schätz- und Liefergewohnheiten konsistent genug sind, um darauf zu planen. Verändert sich die Velocity, ist das eine Information: Etwas im Umfeld oder Prozess des Teams hat sich verändert, und es lohnt sich zu verstehen, was.

Kombinieren Sie sie mit Disziplin bei der Sprint-Planung, sauberen Story-Point-Schätzungen und Flow-Transparenz aus Ihrem Cumulative-Flow-Diagramm, und Sie haben ein Prognosesystem, dem Stakeholder tatsächlich vertrauen können.