„Unser Team hat die Velocity von 30 auf 45 Story Points gesteigert. Warum liefern wir trotzdem nicht schneller?“ Diese Frage begegnet mir regelmäßig.
Die Antwort ist ernüchternd: Velocity ist eine der am häufigsten missverstandenen und falsch eingesetzten Metriken in der Softwareentwicklung.
Was als internes Planungswerkzeug für Scrum-Teams gedacht war, hat sich zu einer pseudo-objektiven Produktivitätskennzahl entwickelt. Teams werden anhand ihrer Story Points verglichen, Manager setzen Velocity-Ziele, und alle wundern sich, warum die erhofften Verbesserungen ausbleiben. Schlimmer noch: In vielen Fällen verschlechtert sich die tatsächliche Leistung, während die Velocity-Zahlen steigen.
Das Problem liegt nicht in der Messung selbst, sondern in dem fundamentalen Missverständnis dessen, was Velocity eigentlich aussagt. Dieser Artikel erklärt, warum Velocity als Produktivitätsmetrik versagt und welche Alternativen Teams und Unternehmen wirklich dabei helfen, ihre Leistung zu verstehen und zu verbessern.
Story Points sind subjektive Schätzungen, die relative Größen ausdrücken sollen. Was als „3 Story Points“ geschätzt wird, kann von Team zu Team völlig unterschiedlich sein. Noch problematischer: Dasselbe Team kann seine Schätzungen über die Zeit verändern, ohne dass sich die tatsächliche Arbeitsleistung ändert.
In der Praxis passiert Folgendes: Sobald Velocity als Leistungsindikator verwendet wird, beginnen Teams unbewusst – oder manchmal auch bewusst – ihre Schätzungen anzupassen. Eine Aufgabe, die früher als „5 Story Points“ geschätzt wurde, wird plötzlich als „8 Story Points“ bewertet. Die Velocity steigt, aber die tatsächliche Arbeitsgeschwindigkeit bleibt gleich oder wird sogar langsamer.
Dieses „Gaming“ des Systems ist oft nicht böswillig, sondern eine natürliche Reaktion auf Leistungsdruck. Teams wollen gute Zahlen liefern und passen unbewusst ihre Schätzungen an. Das Resultat: Velocity-Zahlen werden zu einer Art inflationärer Währung, die immer weniger über die echte Produktivität aussagen.
„Team A schafft 40 Story Points pro Sprint, Team B nur 25 – Team A ist produktiver.“ Diese Schlussfolgerung hört man häufig, sie ist aber fundamental falsch. Story Points sind teamspezifische Schätzungen und lassen sich nicht zwischen Teams vergleichen.
Team A arbeitet vielleicht an einem gut verstandenen Legacy-System mit etablierten Patterns. Team B entwickelt ein völlig neues Produkt mit unbekannten Technologien. Team A schätzt konservativ, Team B optimistisch. Team A arbeitet in einem stabilen Umfeld, Team B wird ständig durch Notfälle unterbrochen. Die Liste der Faktoren, die Velocity beeinflussen, ohne etwas über die tatsächliche Leistung auszusagen, ist lang.
Selbst innerhalb desselben Teams sind Velocity-Vergleiche zwischen verschiedenen Sprints problematisch. Die Art der Aufgaben, externe Störungen, Teamzusammensetzung oder technische Herausforderungen können die Velocity erheblich beeinflussen, ohne dass sich die grundlegende Arbeitsgeschwindigkeit ändert.
Der gravierendste Fehler ist die Gleichsetzung von höherer Velocity mit höherer Produktivität. Wie bereits erläutert, ist Produktivität in der Softwareentwicklung ein komplexes Konzept, das sich nicht in einer einzigen Zahl ausdrücken lässt.
Ein Team kann seine Velocity steigern, indem es:
Echte Produktivität bedeutet jedoch, nachhaltigen Wert für Kunden und Unternehmen zu schaffen. Und das lässt sich nicht allein durch Story Points messen.
Throughput misst, wie viele Arbeitseinheiten ein Team in einem bestimmten Zeitraum abschließt. Statt Story Points zu schätzen, werden einfach fertige Features, Bugfixes oder User Stories gezählt. Die Einheit ist nebensächlich. Wichtig ist die Konsistenz.
Beispiel: „Team A schließt durchschnittlich 12 Arbeitseinheiten pro Iteration ab“ ist aussagekräftiger als „Team A schafft 42 Story Points pro Iteration“. Throughput lässt sich weniger leicht manipulieren und gibt ein direkteres Bild der Arbeitsgeschwindigkeit.
Der Vorteil: Throughput korreliert direkt mit dem, was Stakeholder interessiert – wie viele Dinge werden tatsächlich fertig? Es eliminiert die Subjektivität von Schätzungen und macht Teams weniger manipulierbar.
Implementierung: Statt Story Points zu vergeben, werden Arbeitseinheiten einfach als „done“ oder „not done“ klassifiziert. Am Ende jeder Iteration wird gezählt, wie viele Items abgeschlossen wurden. Nach einigen Iterationen entsteht ein verlässliches Bild der Teamleistung.
Cycle Time misst die Durchlaufzeit von Arbeitseinheiten vom Beginn der Bearbeitung bis zur Fertigstellung. Diese Metrik zeigt, wie effizient das System arbeitet, und ist unabhängig von subjektiven Schätzungen.
Ein praktisches Beispiel: Team B hat eine durchschnittliche Cycle Time von 6 Tagen mit einer Schwankung zwischen 2 und 15 Tagen. Oder noch besser: Ein Cycle-Time-Scatterplot lässt Aussagen mit Perzentilen zu.
Diese Information ist wertvoller als jede Velocity-Zahl, denn sie zeigt:
Cycle Time lässt sich nur schwer „gamen“. Ein Team kann seine Schätzungen aufblähen, aber es kann nicht vortäuschen, dass Aufgaben schneller fertig werden. Diese Metrik zwingt zur Auseinandersetzung mit den echten Problemen, wie Wartezeiten, Unterbrechungen, unklaren Anforderungen oder technischen Hindernissen.
Und wie die DORA-Metriken zeigen, korreliert niedrige Cycle Time stark mit höherer Softwarequalität und Kundenzufriedenheit.
Flow Efficiency misst das Verhältnis von aktiver Arbeitszeit zur gesamten Durchlaufzeit einer Aufgabe. Diese Metrik offenbart eine der größten Verschwendungsquellen in der Softwareentwicklung: Wartezeiten.
Die Berechnung ist einfach: Flow Efficiency = (aktive Arbeitszeit / gesamte Durchlaufzeit) × 100
Typische Werte in der Softwareentwicklung liegen zwischen 10 % und 30 %. Das bedeutet: 70–90 % der Zeit wartet eine Aufgabe darauf, bearbeitet zu werden, liegt in Review-Prozessen fest oder wartet auf Freigaben.
Ein konkretes Beispiel: Feature X hat eine Cycle Time von 20 Tagen, aber wurde nur 4 Tage aktiv bearbeitet. Flow Efficiency: 20 %. Die restlichen 16 Tage entstanden durch Wartezeiten zwischen den Arbeitsschritten. Diese Information ist actionable, denn das Team kann gezielt die Engpässe identifizieren und beseitigen.
Flow Efficiency macht Verschwendung sichtbar, die in Velocity-Messungen völlig untergeht. Ein Team mit hoher Velocity, aber niedriger Flow Efficiency arbeitet ineffizient – auch wenn die Story-Point-Zahlen gut aussehen.
Der Wechsel von Velocity zu aussagekräftigeren Metriken erfordert sowohl technische als auch kulturelle Anpassungen.
Technische Implementierung: Die meisten modernen Ticket-Systeme können Durchlaufzeiten automatisch erfassen. Wichtig ist die Definition klarer Start- und End-Punkte für die Messung. „In Bearbeitung“ bis „Done“ ist oft sinnvoller als „Erstellt“ bis „Done“, da letzteres auch Wartezeiten in der Backlog-Priorisierung einschließt und dann vornehmlich als Lead Time bekannt ist.
Kultureller Wandel: Der schwierigere Teil ist die Kommunikation mit Stakeholdern. Aussagen wie „Wir schaffen mit einer Wahrscheinlichkeit von 85 % 12 Features pro Iteration“ sind anfangs gewöhnungsbedürftig, aber deutlich informativer als „Wir haben 42 Story Points erreicht“.
Graduelle Einführung: Viele Teams führen die neuen Metriken parallel zu Velocity ein und zeigen über Monate die Korrelation – oder deren Fehlen. Wenn Velocity steigt, aber Throughput sinkt und Cycle Time zunimmt, wird das Problem für alle sichtbar.
Und wie im Goals-Signals-Metrics-Framework beschrieben, sollten Metriken immer im Kontext konkreter Ziele betrachtet werden. Die Frage „Wozu messen wir?“ ist wichtiger als „Was messen wir?“.
Eine der größten Herausforderungen beim Abschied von Velocity ist die Kommunikation mit Managern, Product Ownern und anderen Stakeholdern, die sich an Story-Point-Zahlen gewöhnt haben.
Die Wahrheit über Schätzungen: Studien zeigen, dass menschliche Schätzungsgenauigkeit bei komplexen Aufgaben extrem limitiert ist. Die Forschung von Daniel Kahneman und anderen Verhaltensökonomen belegt: Menschen sind systematisch schlecht darin, die Dauer von Wissensarbeit vorherzusagen. Story Points verstärken diese Problematik, indem sie den Eindruck von Präzision vermitteln, wo keine existiert.
Alternative Kommunikationsformen: Statt „Wir schaffen 35 Story Points pro Sprint“ wird kommuniziert: „Wir liefern durchschnittlich 8–10 Features pro Sprint, jedes Feature braucht 4–7 Tage von Start bis Finish.“ Diese Information ist für Geschäftsentscheidungen deutlich wertvoller.
Vorhersagbarkeit durch historische Daten: Mit Throughput und Cycle Time lassen sich mittelfristige Prognosen erstellen, die verlässlicher sind als Story-Point-basierte Schätzungen. Monte-Carlo-Simulationen, basierend auf historischen Durchlaufzeiten, liefern realistische Wahrscheinlichkeitsverteilungen für Projektabschlüsse.
Velocity-Fixierung ist oft ein Symptom für tieferliegende Probleme im Verständnis von Entwicklerproduktivität. Das SPACE-Framework zeigt, dass Produktivität in der Softwareentwicklung multidimensional ist und sich nicht in einer einzigen Metrik ausdrücken lässt.
Satisfaction (Zufriedenheit), Performance (Leistung), Activity (Aktivität), Communication (Kommunikation) und Efficiency (Effizienz) – alle diese Dimensionen sind relevant für die Teamleistung. Velocity erfasst bestenfalls einen kleinen Teil der Activity-Dimension und ignoriert alle anderen Aspekte völlig.
Teams mit hoher Velocity, aber niedriger Satisfaction brennen aus. Teams mit moderater Velocity, aber exzellenter Communication und Efficiency können nachhaltigen Wert schaffen. Die Fokussierung auf Story Points blendet diese wichtigen Aspekte aus.
Velocity ist nicht grundsätzlich schlecht. Als internes Planungstool für Teams kann sie durchaus ihren Zweck erfüllen. Problematisch wird sie erst, wenn sie als objektive Produktivitätskennzahl missbraucht wird.
Die Alternative liegt nicht in noch komplexeren Metriken, sondern in einfacheren, ehrlicheren Messungen. Throughput, Cycle Time und Flow Efficiency geben ein realistischeres Bild der Teamleistung und lassen sich weniger leicht manipulieren.
Der Wechsel zu besseren Metriken erfordert Mut zur Ehrlichkeit. Statt sich hinter aufgeblähten Story-Point-Zahlen zu verstecken, müssen Teams und Manager bereit sein, sich den echten Problemen zu stellen: ineffiziente Prozesse, schlechte Codequalität, unklare Anforderungen oder organisatorische Hindernisse.
Unternehmen, die diesen Schritt gehen, werden mit verlässlicheren Prognosen, motivierteren Teams und letztlich besseren Produkten belohnt. Die Zeit der Story-Point-Inflation ist vorbei und es wird Zeit für Metriken, die wirklich helfen.
Buchen Sie jetzt Ihre kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.