Velocity

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 und Geschwindigkeit sagt nichts darüber aus, ob Mehrwerte geschaffen wurden.

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. Und daraus ergibt sich auch, dass Velocity kein gutes Kriterium ist, ein Team zu bewerten. Es ist eine Flow-Metrik des Teams für das Team und keine Performance-Metrik für das Management.

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:

• The Colossal Danger inherent in Velocity – Beitrag von Derek Davidson auf scrum.org.
• Agile Missverständnisse: Das Ende der Velocity? – Beitrag von Björn Schotte bei Mayflower.
• Weekly Scrum Interview Question: What Is Velocity? – Beitrag von Alex Kudinov auf scrum.org.
• Three Approaches to Estimating the Impact of Holidays and Time Off on Velocity – Beitrag von Mike Cohn bei Mountain Goat Software.
• Was bedeutet Velocity für Ihr Team? – Beitrag bei agile academy.
• The Illusion of Velocity – Beitrag von Stefan Wolpers auf scrum.org.

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:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.