Wer im agilen Umfeld arbeitet, stößt früher oder später auf den Begriff Velocity. Er klingt technisch, ist aber eigentlich eine ganz praktische Sache: Wie viel schafft ein Scrum-Team in einem Sprint? Die Antwort auf diese Frage hilft nicht nur beim Planen, sondern auch dabei zu verstehen, wie ein Team wirklich arbeitet. Velocity gehört damit zu den grundlegenden Projektmanagement-Methoden, die agile Teams in ihrem Alltag einsetzen.
In diesem Artikel schauen wir uns an, was Velocity im Scrum-Kontext bedeutet, wie sie berechnet wird, was sie beeinflusst und wo Teams bei ihrer Nutzung häufig auf die Nase fallen.
Velocity als Planungsgrundlage im Scrum-Team
Velocity beschreibt die durchschnittliche Menge an Story Points, die ein Scrum-Team in einem Sprint abschließt. Sie ist kein Leistungsurteil, sondern ein Planungswerkzeug. Teams nutzen sie, um realistisch einzuschätzen, wie viel Arbeit in einem kommenden Sprint machbar ist.
Der Grundgedanke ist einfach: Wenn ein Team in den letzten drei Sprints jeweils zwischen 30 und 40 Story Points abgeschlossen hat, ist es vernünftig anzunehmen, dass der nächste Sprint ähnlich aussehen wird. Das gibt dem Product Owner eine solide Basis, um das Sprint Backlog sinnvoll zu befüllen, ohne das Team zu überlasten oder zu unterfordern.
Wichtig dabei: Velocity ist immer teamspezifisch. Ein Vergleich zwischen verschiedenen Teams ist wenig sinnvoll, weil jedes Team Story Points nach seinem eigenen Verständnis schätzt. Was Team A als 5 Punkte einschätzt, kann bei Team B 8 Punkte sein. Velocity sagt etwas über ein Team im Zeitverlauf aus, nicht über Teams im Vergleich.
Plane jetzt Projekte mit deinem Team ganz digital, schnell und unkompliziert mit einem Tool, dass dir bei allen Projekten hilft.Kostenlos testenSo wird die Velocity im Scrum berechnet
Die Berechnung der Velocity ist unkompliziert. Am Ende jedes Sprints werden die Story Points aller abgeschlossenen User Stories zusammengezählt. Nur vollständig fertiggestellte Aufgaben zählen, also solche, die die Definition of Done erfüllen. Halbfertige Arbeit geht nicht in die Zahl ein.
Für die Planung nimmt man dann den Durchschnitt aus mehreren vergangenen Sprints, in der Regel drei bis fünf. Das glättet Ausreißer und gibt ein realistischeres Bild als ein einzelner Sprint. Ein Beispiel: Wenn ein Team in den letzten vier Sprints 32, 38, 35 und 41 Story Points abgeschlossen hat, liegt die durchschnittliche Velocity bei 36,5 Punkten.
Story Points richtig schätzen
Damit die Velocity aussagekräftig ist, müssen Story Points konsistent geschätzt werden. Viele Teams nutzen Planning Poker, um gemeinsam zu einer realistischen Einschätzung zu kommen. Dabei geht es nicht darum, wie lange etwas dauert, sondern darum, wie komplex und aufwändig eine Aufgabe im Vergleich zu anderen ist. Diese relative Schätzung ist der Kern des Story-Point-Konzepts.
Einflussfaktoren auf die Scrum Velocity
Velocity schwankt, und das ist normal. Wer die Gründe kennt, kann besser damit umgehen und die Planung entsprechend anpassen.
Zu den häufigsten Einflussfaktoren gehören:
- Teamveränderungen: Neue Teammitglieder brauchen Zeit, um sich einzuarbeiten. Das senkt die Velocity kurzfristig, auch wenn es langfristig sinnvoll ist.
- Urlaub und Krankheit: Weniger verfügbare Kapazität bedeutet weniger abgeschlossene Story Points. Das ist keine Schwäche, sondern Realität.
- Technische Schulden: Wenn ein Team viel Zeit mit Bugfixes oder Refactoring verbringt, bleibt weniger Kapazität für neue Features.
- Unklare Anforderungen: Wenn User Stories nicht gut genug ausgearbeitet sind, entstehen während des Sprints ungeplante Abstimmungsschleifen, die Zeit kosten.
- Externe Abhängigkeiten: Wartezeiten auf andere Teams oder Systeme können einen Sprint bremsen, ohne dass das Scrum-Team selbst daran schuld ist.
Wer diese Faktoren im Blick behält, kann Velocity-Schwankungen besser einordnen und vermeidet es, falsche Schlüsse zu ziehen.
Typische Fehler bei der Nutzung von Velocity
Velocity ist nützlich, wird aber häufig missverstanden oder falsch eingesetzt. Hier sind die Fehler, die Teams am häufigsten machen.
Der größte Fehler ist, Velocity als Produktivitätskennzahl zu behandeln. Wenn Führungskräfte von Sprint zu Sprint eine steigende Velocity erwarten, geraten Teams unter Druck, Story Points aufzublähen oder Aufgaben als fertig zu markieren, die es nicht sind. Das untergräbt die Qualität und macht die Metrik wertlos.
Ein weiterer häufiger Fehler ist der Vergleich zwischen Teams. Wie bereits erwähnt, schätzen verschiedene Teams unterschiedlich. Ein Team mit einer Velocity von 60 ist nicht zwingend produktiver als eines mit 30.
Außerdem verlassen sich manche Teams zu sehr auf die Velocity und vernachlässigen andere wichtige Signale wie Qualität, Kundenzufriedenheit oder technische Gesundheit des Codes. Velocity misst Durchsatz, nicht Wert.
Plane jetzt Projekte mit deinem Team ganz digital, schnell und unkompliziert mit einem Tool, dass dir bei allen Projekten hilft.Kostenlos testenVelocity im Zusammenspiel mit anderen Scrum-Metriken
Velocity entfaltet ihren vollen Nutzen erst im Zusammenspiel mit anderen Metriken. Allein betrachtet erzählt sie nur einen Teil der Geschichte.
Besonders relevant ist die Kombination mit dem Sprint Burndown Chart, das zeigt, wie gleichmäßig die Arbeit im Sprint abgebaut wird. Wenn die Velocity stabil ist, der Burndown aber immer wieder zeigt, dass Arbeit sich auf die letzten Tage ballt, gibt das Hinweise auf Planungs- oder Schätzprobleme.
Auch der Release Burnup profitiert von einer stabilen Velocity. Wenn bekannt ist, wie viele Story Points ein Team pro Sprint schafft, lässt sich hochrechnen, wann ein bestimmter Scope fertiggestellt sein wird. Das ist für die Kommunikation mit Stakeholdern sehr wertvoll.
Ergänzend dazu gibt die Defect Rate Aufschluss darüber, ob eine hohe Velocity auf Kosten der Qualität geht. Steigt die Anzahl der Bugs, während die Velocity steigt, sollte das Team innehalten und prüfen, ob die Definition of Done noch konsequent eingehalten wird.
Wie smenso bei der Scrum-Planung hilft
Agile Projektmanagement-Methoden wie Scrum funktionieren am besten, wenn das Team alle relevanten Informationen an einem Ort hat und nicht zwischen verschiedenen Tools jonglieren muss. Genau hier kommen wir ins Spiel.
Mit smenso kannst du Sprints strukturieren, Story Points vergeben und den Fortschritt deines Teams transparent machen. Das hilft dir konkret dabei:
- Sprints und Backlogs übersichtlich zu verwalten und anzupassen
- Aufgaben mit benutzerdefinierten Feldern wie Story Points oder Prioritäten zu versehen
- Dashboards zu erstellen, die Velocity und Sprint-Fortschritt auf einen Blick zeigen
- Statusupdates direkt in der Plattform zu teilen, damit alle Beteiligten informiert bleiben
- Microsoft Teams und andere Tools zu integrieren, um Silos zu vermeiden
smenso ist 100% DSGVO-konform und wird in Deutschland entwickelt und betrieben. Wenn du wissen willst, wie wir dein agiles Team unterstützen können, schau gern auf unserer Projektmanagement-Seite vorbei oder nimm direkt Kontakt mit uns auf.
