Wissen kompakt: Die Velocity ist ein Maß zur Geschwindigkeitsmessung von Entwicklungen, basiert auf realisierten Story Points und hilft bei der Planung von Sprints.

Velocity – die Geschwindigkeit des Entwicklungsteams

Das englische Wort “Velocity” heißt ins Deutsche übersetzt Geschwindigkeit bzw. Schnelligkeit. In Scrum gilt die Velocity bzw. der Velocity-Faktor als Maßeinheit für die Geschwindigkeit eines Teams. Sie wird häufig mithilfe sogenannter Story Points bestimmt. Story Points sind eine Einheit zur Beschreibung der Größe einer User Story und repräsentieren den Entwicklungsaufwand und die Faktoren, die diesen Aufwand beeinflussen.¹ Die Erhebung der durchschnittlich – über einen Zeitraum von mehreren Sprints – erledigten Story Points ist ein Hilfsmittel zur Planung zukünftiger Sprints.

Beispiel:

  • In Sprint 1 werden 10 Story Points, in Sprint 2 sogar 16 Story Points realisiert. Die folgende Sprint Planung basiert auf 13 Story Points (sofern die gleiche Anzahl von Mitarbeitern und Arbeitstagen zur Verfügung stehen).
  • In Sprint 3 werden 19 Story Points realisiert. Die Planung für den 4. Sprint geht nun von 15 Story Points [((10 + 16 + 19) / 3) = 15] aus.

 

Velocity - die Geschwindigkeit des Entwicklungsteams

Verwendung der Velocity im Sprint Planning

Unabhängig von der Art der Berechnung ist es für Organisationen wichtig, die durchschnittliche Velocity im Sprint Planning – und nicht die maximale oder die höchste Geschwindigkeit der letzten Sprints – zu berücksichtigen. Es gehört zu den Prinzipien des Agilen Manifests durch ein gleichmäßiges Tempo, das Auftraggeber, Entwickler und Benutzer über einen unbegrenzten Zeitraum halten können, eine nachhaltige Entwicklung zu fördern. Inhalte sind wichtiger als Schnelligkeit.

Wäre die Steigerung der Geschwindigkeit das Ziel, würde eine Art Inflation der Story Points drohen: eine auf die Steigerung der Geschwindigkeit ausgelegte Velocity lässt sich bspw. durch die Erhöhung der Schätzwerte erreichen; damit wäre der Sinn der Schätzung mittels Story Points konterkariert.

Auch der Vergleich der Geschwindigkeit einzelner Teams in einer Organisation basierend auf der Velocity ist keine gute Idee.  Sie ist ein team-internes Hilfsmittel zur Planung und zur Risikokontrolle. Wer Teams einer Organisation durch den Vergleich untereinander, basierend auf geplanten oder realisierten Story Points anzutreiben versucht, tut sich keinen Gefallen. Auch dies wird zu einer Inflation der Schätzungen führen. Hier sind sowohl der Scrum Master als auch die Entwickler gefordert, diese Fehlentwicklung möglichst frühzeitig zu unterbinden.

Interpretationen der Velocity

Ist es möglich, mehr Story Points zu realisieren als geplant wurden? Die Beantwortung dieser Frage führt zu zwei unterschiedlichen Interpretationen und Wegen zur Berechnung der Geschwindigkeit:

  • Manche Organisationen betrachten die zusätzlich geschaffene Funktionalität, die durch Backlog Items bzw. User Storys formuliert und entsprechend in den Sprints umgesetzt wird. Wurden in einem Sprint 5 Storys mit insgesamt 16 Story Points eingeplant und entsprechend realisiert, dann ist die Velocity des Sprints 16 Story Points.
  • Andere Organisationen betrachten neben ursprünglich geplanten User Storys und Story Points auch Aufgaben, die im Laufe eines Sprints hinzukamen. Solche Aufgaben können bspw. durch Bugfixing oder Refactoring notwendig werden.  Es kann also sein, dass ein Team eine höhere Velocity erreicht als ursprünglich geplant.

 

Visualisierung der Velocity

Visualisiert wird die Geschwindigkeit mit einem Velocity Chart. Das sogenannte Velocity Offset als Summe, der nicht in einem Sprint realisierten User Storys, lässt sich aus dem Diagramm ebenfalls ablesen. Hier sollte sich das Entwicklungsteam – idealerweise gemeinsam mit dem Scrum Master – überlegen, wo die Ursachen für die Abweichung zwischen den geplanten und realisierten User Storys bzw. Product Backlog Items liegen. Aus den Erkenntnissen lassen sich Rückschlüsse für künftige Planungen ziehen.

Alternative Metriken in agilen Vorhaben

In vielen Unternehmen wird die Velocity basierend auf Story Points zur Planung der Arbeit genutzt. Darüber hinaus gibt es zahlreiche weitere agile Metriken, die zum Einsatz kommen könnten:

  • Backlog Health: ein Maß für den allgemeinen Zustand und die Effizienz des Backlogs des Teams, einschließlich Faktoren wie Backlog-Größe, veraltete Elemente und Fortschritte bei der Fertigstellung.
  • Cycle Time: die Zeit, die ein Team benötigt, um eine Aufgabe von Anfang bis Ende zu erledigen.
  • Escaped Defects: Die Anzahl der Fehler, die trotz der Bemühungen des Teams, sie zu vermeiden, in das Endprodukt gelangen.
  • Fehlerdichte: die Anzahl der Fehler pro Arbeitseinheit.
  • Flow-Efficiency: der Prozentsatz der Zeit, in der ein Team tatsächlich an der Wertschöpfung arbeitet, anstatt auf Ressourcen oder Genehmigungen zu warten.
  • Kundenzufriedenheit: ein Maß dafür, wie zufrieden die Kunden mit der Arbeit des Teams sind.
  • Lead Time: die Zeit, die von der Anforderung einer Aufgabe durch einen Kunden bis zur Lieferung der Aufgabe vergeht.
  • Mean Time To Repair (MTTR): die durchschnittliche Zeit, die für die Reparatur eines Fehlers benötigt wird.
  • Prozentsatz der Nacharbeit: der Prozentsatz der Arbeit, die aufgrund von Mängeln oder anderen Problemen nachgearbeitet wird.
  • Team-Moral: ein allgemeines Maß für das Engagement und die Motivation des Teams, das durch Umfragen oder andere Formen des Feedbacks ermittelt wird.
  • Time to Market: Die Zeit, die ein Team benötigt, um ein Produkt oder eine Funktion auf den Markt zu bringen.
  • Time to Value: Die Zeit, die ein Team benötigt, um dem Kunden einen greifbaren Wert zu liefern.
  • Work in Progress (WIP): Die Menge der Arbeit, die derzeit im System in Bearbeitung ist. Diese Kennzahl kann Teams helfen, Engpässe zu erkennen und Multitasking zu reduzieren, insbesondere in Kombination mit dem WIP Limit als maximale Anzahl von Aufgaben, an denen ein Team zu einem bestimmten Zeitpunkt arbeiten kann.

Sicherlich lässt sich diese Liste ergänzen. Der Scrum Guide definiert keine explizite agile Metrik; Organisationen müssen sich also für eine oder mehrere Metriken zur Planung und Realisierung ihrer Arbeit entscheiden. Manche Metriken wie bspw. die Cycle Time oder die Flow-Efficiency haben direkten Einfluss auf die Ergebnisse eines Sprints. Andere hingegen entfalten ihre Wirkung indirekt wie bspw. Backlog Health oder die Team-Moral.

Velocity in der Praxis

Hier finden Sie einige englisch- und deutschsprachige Beiträge, die sich der Velocity in der Praxis beschäftigen:

Gerne ergänzen wir die Liste mit weiteren spannenden Beiträgen.

Impuls zum Diskutieren:

Führt die Verwendung der Velocity, insbesondere wenn sie als Zielkennzahl verstanden wird, zur stärkeren Fokussierung auf Quantität statt Qualität?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Im Scrum Guide werden weder Velocity noch User Storys oder Story Points als Begriffe erwähnt. Dennoch werden diese Konstrukte häufig in Projekten und Entwicklungen verwendet, die Scrum nutzen.

In manchen Publikationen wird von Developer Velocity gesprochen. In den meisten Fällen meint diese die individuelle Geschwindigkeit eines einzelnen Entwicklers.

“Scrum, The Art of Doing Twice the Work in Half the Time” lautet ein Scrum-Bestseller. Hier finden Sie einen Beitrag über die agile Geschwindigkeitslüge.

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

 Wissen kompakt: Was steht im Scrum Guide und was nicht?

Was steht im Scrum Guide und was nicht?

Wissen kompakt: Was ist das INVEST-Prinzip bei einer User Story?

Was ist das INVEST-Prinzip bei einer User Story?

Wissen kompakt: Was ist Extreme Programming?

Was ist Extreme Programming?