"Velocity ist eine Lüge – und alle wissen es"

Februar 2026 9 Min. Lesezeit Meinung + Fallstudie

Jedes Scrum-Team trackt sie. Jeder Manager fragt danach. Und fast niemand vertraut ihr wirklich. Velocity ist die am weitesten verbreitete Metrik in Agile – und vermutlich die am meisten missverstandene.

Die Realität: Eine Zahl, die nach Fortschritt aussieht

Geh in das Sprint Review irgendeines Scrum-Teams und du siehst sie auf einem Chart. Story Points pro Sprint, über die Zeit aufgetragen, im besten Fall mit aufsteigendem Trend. Das Team meldet 34 Punkte in diesem Sprint, nach 28 im letzten. Der Manager nickt. Fortschritt.

Aber stell die schwierigere Frage: Fortschritt worauf hin, genau?

Velocity wurde als Planungswerkzeug entwickelt – als Methode für Teams, realistisch einzuschätzen, wie viel Arbeit sie in einem Sprint schaffen können. Das war der Gedanke dahinter. Sie war nie dazu gedacht, Produktivität, Qualität, Team-Performance oder gelieferten Geschäftswert zu messen. Irgendwann auf dem Weg ist sie aber zu all diesen Dingen geworden.

“Velocity ist ein Kapazitätsplanungswerkzeug, kein Performance-Indikator. In dem Moment, in dem du sie nutzt, um ein Team zu beurteilen, hast du sie kaputt gemacht.” Markus – agile-checksum.com

Der State of Agile Report zeigt Velocity Jahr für Jahr als eine der meistgetrackten Metriken in Unternehmen. Sie ist sichtbar, sie ist numerisch, sie wirkt objektiv. Das macht sie perfekt für Dashboards – und gefährlich für Entscheidungen.

---

Der Checksum: Was Velocity wirklich misst

Zurück zu den Grundlagen. Der Scrum Guide erwähnt Velocity kein einziges Mal. Nicht einmal. Sie ist eine Community-Praxis, die aus dem Bedarf entstanden ist, Sprint-Kapazitäten zu prognostizieren – und dieser Kontext ist entscheidend.

Die drei grundlegenden Probleme

Velocity hat drei strukturelle Schwächen, die sie als alles andere als ein grobes internes Planungswerkzeug unzuverlässig machen.

1. Story Points sind nicht standardisiert

Eine 5-Punkte-Story in Team A bedeutet etwas völlig anderes als eine 5-Punkte-Story in Team B. Story Points spiegeln die relative Schätzung eines Teams für Aufwand und Komplexität wider – sie sind bewusst subjektiv und teamspezifisch. Velocity über Teams hinweg zu vergleichen ist daher sinnlos. Es ist wie Temperaturen in Celsius und Fahrenheit zu vergleichen, ohne umzurechnen: Die Zahlen sehen ähnlich aus, bedeuten aber völlig unterschiedliche Dinge.

Glossar: Story Points sind eine Maßeinheit für die Gesamtgröße einer User Story, eines Features oder eines anderen Arbeitspakets. Sie repräsentieren Aufwand, Komplexität und Unsicherheit – keine Stunden.

2. Velocity bläht sich unter Druck auf

Das ist das, was alle wissen, aber im Sprint Review niemand laut sagt. Wenn das Management anfängt, Velocity als Performance-Indikator zu tracken, passen Teams ihre Schätzungen – bewusst oder unbewusst – nach oben an. Stories, die 3 Punkte wert waren, werden zu 5. Die Velocity steigt. Die Arbeit verändert sich nicht. Alle fühlen sich besser. Nichts verbessert sich.

Das ist ein Paradebeispiel für Goodharts Gesetz: Wenn ein Maß zum Ziel wird, hört es auf, ein gutes Maß zu sein.

3. Velocity ignoriert Wert

Ein Team kann eine konstant hohe Velocity haben und dabei kaum Geschäftswert liefern. Sie schließen Stories ab, treffen ihre Zahlen und liefern Features, die niemand nutzt. Velocity misst Output, keinen Outcome. Und bei Agile sollen Outcomes eigentlich der Punkt sein.

Warnsignal: Wenn deine Organisation Velocity verwendet, um Teams zu vergleichen, Ziele zu setzen oder Personalentscheidungen zu treffen – hör damit auf. Du misst die falschen Dinge und schaffst die falschen Anreize.

---

Praxisbeispiele: Was ich im Feld gesehen habe

In über 20 Jahren Enterprise-IT habe ich Velocity auf Weisen missbraucht gesehen, die von mäßig kontraproduktiv bis wirklich schädlich reichen. Hier sind drei anonymisierte Muster, denen ich immer wieder begegnet bin.

Das Velocity-Rennen

Ein großes Finanzdienstleistungsunternehmen – mehrere Scrum-Teams, gemeinsames Portfolio, gemeinsame Quartalsplanung. Jemand in der Führungsebene kam auf die Idee, die Velocities aller Teams in einem gemeinsamen Dashboard anzuzeigen. Öffentlich. Wöchentlich aktualisiert.

Innerhalb von zwei Sprints waren die durchschnittlichen Story-Point-Schätzungen aller Teams um rund 40 % gestiegen. Die Arbeit hatte sich nicht verändert. Die Teams hatten einfach ihre Schätzungen nach oben korrigiert, um nicht am Ende der Bestenliste zu erscheinen. Als ich das in einer Retrospective ansprach, war die Reaktion eines Senior-Developers: “Wir alle wussten, dass es passiert. Niemand wollte das Team sein, das langsam aussieht.”

Der Velocity-Vertrag

Ein mittelgroßes Softwareunternehmen verhandelte einen Entwicklungsvertrag mit einem externen Scrum-Team. Der Vertrag enthielt eine Klausel, die eine Mindest-Velocity von 60 Story Points pro Sprint vorgab. Das externe Team stimmte zu.

Ab Sprint drei trafen sie konstant 65–70 Punkte. Beeindruckend – bis die internen Stakeholder merkten, dass die Qualität der Lieferergebnisse sank, Bugs zunahmen und die Definition of Done stillschweigend aufgeweicht wurde. Hohe Velocity, geringer Wert. Die Vertragsmetrik war erfüllt. Das Projekt scheiterte.

Das Velocity-Plateau

Ein Produktteam, das ich gecoacht hatte, hatte sechs Monate lang eine stabile Velocity von rund 45 Punkten gehalten. Ihr Manager sah das als Problem – sollten sie nicht schneller werden? Er drängte das Team, die Velocity innerhalb des nächsten Quartals um 20 % zu steigern.

Was er nicht verstand: Eine stabile Velocity ist oft ein Zeichen für ein gesundes Team. Sie bedeutet, dass Schätzungen konsistent sind, Technical Debt gemanagt wird und das Team sich nicht überlädt. Eine stabile Velocity ist keine Stagnation – sie ist Zuverlässigkeit. Und genau das willst du von einem Planungswerkzeug.

---

Was die Zahlen wirklich zeigen

Die Ironie eines Abschnitts mit dem Titel “Was die Zahlen zeigen” in einem Artikel über die Gefahr von Zahlen geht mir nicht verloren. Aber lass uns Daten richtig einsetzen – als Kontext, nicht als Urteil.

Velocity genutzt als…	Was sie misst	Was sie ausblendet
Sprint-Kapazitätsplanung	Wie viel ein Team bewältigen kann	Qualität, Komplexitätsschwankungen
Team-Performance-Indikator	Abgeschlossene Story Points	Geschäftswert, Outcomes, Qualität
Teamübergreifender Vergleich	Nichts Aussagekräftiges	Alles, was zählt
Fortschrittsreporting ans Management	Output-Aktivität	Ob die richtigen Dinge gebaut werden
Vertrags-Performance-Metrik	Einhaltung einer Zahl	Gelieferter Wert, Qualität, Nachhaltigkeit

---

Bessere Alternativen: Was stattdessen messen?

Eine Metrik zu kritisieren ohne Alternativen anzubieten ist bloßes Klagen. Deshalb hier meine Empfehlungen, abhängig davon, was du wirklich verstehen willst.

Wenn du Team-Gesundheit messen willst

• Sprint Goal Achievement Rate – Hat das Team geliefert, wozu es sich beim Sprint Planning verpflichtet hat? Das misst Zuverlässigkeit und Fokus.
• Escaped Defects – Wie viele Bugs haben es in die Produktion geschafft? Eine steigende Zahl ist ein Qualitätsproblem, das dir Velocity niemals zeigen wird.
• Team Satisfaction Score – Eine einfache 1–5-Skala in jeder Retrospective. Sinkende Werte kündigen Probleme an, bevor sie in irgendeiner Output-Metrik sichtbar werden.

Wenn du Geschäftswert messen willst

• Outcome-Metriken – User Adoption, Conversion Rates, Support-Ticket-Volumen – was auch immer für das Produkt relevant ist. Das sind die Metriken, die dir wirklich sagen, ob die Arbeit etwas bewirkt.
• Cycle Time – Wie lange dauert es von “Story gestartet” bis “in Produktion”? Das misst Flow-Effizienz, nicht Team-Geschwindigkeit.
• Net Promoter Score (NPS) – Bei kundenzugewandten Produkten ist Nutzerzufriedenheit die ultimative Output-Metrik.

Wenn du nach oben berichten musst

Praktischer Tipp: Ersetze Velocity-Charts in deinem Management-Reporting durch einen einfachen “Sprint Goal erfüllt / nicht erfüllt”-Indikator plus einen Satz Erklärung warum. Das ist ehrlicher, aussagekräftiger und kostet weniger Zeit in der Erstellung.

---

Das Fazit: Nutz sie wofür sie gebaut wurde

Velocity ist nicht nutzlos. Korrekt eingesetzt – als internes, teamspezifisches, Sprint-für-Sprint-Planungsreferenzwerkzeug – ist sie ein vollkommen vernünftiges Instrument. Das Problem ist nie das Werkzeug selbst. Das Problem ist, was passiert, wenn eine Planungsheuristik zum Performance-Indikator befördert wird.

In dem Moment, in dem Velocity auf einem Management-Dashboard erscheint, in dem Moment, in dem sie zum Teamvergleich genutzt wird, in dem Moment, in dem sie zum Ziel wird – fängt sie an, das Verhalten zu verzerren, das sie eigentlich unterstützen sollte. Teams hören auf, ehrlich zu schätzen. Qualität erodiert still. Und alle tun so, als würden sie es nicht bemerken, weil die Zahl gut aussieht.

Führ den Checksum für deine Organisation durch. Stell diese drei Fragen:

1. Wer hat Zugang zu den Velocity-Daten deines Teams, und wofür werden sie genutzt?
2. Steigt deine Velocity stetig, ohne dass es einen klaren Grund dafür gibt?
3. Kannst du mir jetzt, auf der Stelle, sagen, welchen Geschäftswert die Velocity des letzten Sprints tatsächlich geliefert hat?

Wenn die Antworten dich unwohl fühlen lassen – genau das ist der Punkt. Unbehagen ist der Ort, an dem ehrliche Gespräche beginnen.

“Das Ziel von Agile ist nicht, schneller zu werden. Es ist, schneller zu lernen. Velocity misst keines von beidem.” Markus – agile-checksum.com

---

Im Artikel verwendete Glossarbegriffe

• Velocity – Ein Maß für die Arbeitsmenge, die ein Scrum-Team in einem Sprint abschließt, ausgedrückt in Story Points.
• Story Points – Eine relative Schätzeinheit, die Aufwand, Komplexität und Unsicherheit widerspiegelt.
• Definition of Done – Die gemeinsame Vereinbarung darüber, was “fertig” für ein Produkt-Increment bedeutet.
• Technical Debt – Die impliziten Kosten für Nacharbeit, die entstehen, wenn man jetzt eine schnelle Lösung wählt statt eines besseren Ansatzes.
• Sprint – Ein fixer Zeitrahmen von 1–4 Wochen, in dem ein Scrum-Team ein potenziell auslieferbares Increment liefert.