Velocity

Velocity ist ein zentrales Konzept in agilen Frameworks wie Scrum und bezieht sich auf die Menge an Arbeit, die ein Entwicklungsteam in einem Sprint oder einer Iteration fertigstellen kann. Dieses Maß wird üblicherweise in Story Points ausgedrückt, kann aber auch auf andere Einheiten wie die Anzahl der Backlog-Items oder Arbeitsstunden basieren.

Definition und Berechnung

Velocity wird definiert als die Summe der Story Points aller User Stories (oder anderer Backlog-Items), die in einem Sprint vollständig abgeschlossen wurden und die Definition of Done erfüllen. Stories, die nicht vollständig fertiggestellt wurden, fließen nicht in die Velocity ein, unabhängig davon, wie weit sie fortgeschritten sind.

Die Berechnung erfolgt typischerweise nach jedem Sprint:

1. Identifizieren aller abgeschlossenen User Stories im Sprint
2. Summieren der Story Points dieser Stories
3. Dokumentation des Ergebnisses als Sprint-Velocity

Für eine aussagekräftige Velocity-Messung sollten mehrere Sprints betrachtet werden, wobei folgende Berechnungen üblich sind:

• Durchschnittliche Velocity: Summe der Story Points über mehrere Sprints geteilt durch die Anzahl der Sprints
• Median-Velocity: Der mittlere Wert aller Sprint-Velocities, weniger anfällig für Ausreißer
• Gleitender Durchschnitt: Durchschnitt der letzten n Sprints (typischerweise 3-5), um aktuelle Trends besser zu erfassen

Zweck und Nutzen der Velocity

Die Velocity dient mehreren wichtigen Zwecken in agilen Projekten:

Sprint-Planung

• Ermöglicht Teams, eine realistische Menge an Arbeit für den nächsten Sprint zu planen
• Verhindert Überladung des Sprints mit zu vielen Stories
• Fördert verlässliche Zusagen gegenüber Stakeholdern

Release-Planung

• Hilft bei der Prognose, wann Features oder Releases fertiggestellt sein werden
• Ermöglicht die Berechnung, wie viele Sprints für die Umsetzung eines Produktbacklogs benötigt werden
• Unterstützt datenbasierte Entscheidungen über Umfang und Zeitrahmen

Kontinuierliche Verbesserung

• Bietet eine Metrik zur Messung der Teamleistung über Zeit
• Ermöglicht die Identifikation von Trends und Mustern
• Hilft bei der Bewertung der Auswirkungen von Prozessänderungen

Faktoren, die die Velocity beeinflussen

Die Velocity eines Teams wird von zahlreichen Faktoren beeinflusst:

Teamfaktoren

• Teamgröße und -zusammensetzung: Änderungen in der Teamgröße oder im Skill-Mix wirken sich direkt auf die Velocity aus
• Teamreife: Teams durchlaufen typischerweise die Phasen Forming, Storming, Norming und Performing mit steigender Velocity
• Verfügbarkeit: Urlaub, Krankheit oder Teilzeitarbeit reduzieren die verfügbare Kapazität
• Lernen und Wachstum: Mit zunehmender Erfahrung und verbesserten Fähigkeiten steigt die Velocity oft an

Prozessfaktoren

• Definition of Done: Striktere Kriterien können die Velocity kurzfristig senken, aber die Qualität erhöhen
• Technische Schulden: Ansammlung von technischen Schulden kann die Velocity im Laufe der Zeit verringern
• Sprint-Länge: Änderungen in der Sprint-Dauer erfordern eine Neukalibration der Velocity
• Story-Splitting-Praktiken: Wie Teams Stories aufteilen, beeinflusst deren Größe und damit die Velocity

Externe Faktoren

• Unterbrechungen: Unerwartete Anfragen, Produktionsprobleme oder Meetings
• Technische Infrastruktur: Probleme mit Entwicklungsumgebungen oder CI/CD-Pipelines
• Abhängigkeiten: Warten auf externe Teams oder Lieferanten
• Organisatorischer Kontext: Restrukturierungen, Strategieänderungen oder Budgetkürzungen

Häufige Missverständnisse und Fallstricke

Bei der Anwendung des Velocity-Konzepts sollten folgende Missverständnisse vermieden werden:

Velocity als Leistungsbewertung

Velocity wurde nie als Maß für Produktivität oder zur Bewertung einzelner Teammitglieder konzipiert. Sie sollte nicht verwendet werden, um:

• Teams miteinander zu vergleichen (jedes Team hat seine eigene Skala)
• Leistung von Teammitgliedern zu bewerten
• Bonuszahlungen oder Beförderungen zu bestimmen
• Teams unter Druck zu setzen, die Velocity künstlich zu erhöhen

Velocity-Inflation

Wenn die Velocity als Leistungsmetrik missbraucht wird, führt dies oft zu:

• Überschätzung von Story Points ("Story Point Inflation")
• Fokus auf Geschwindigkeit statt Qualität
• Vernachlässigung technischer Schulden
• Manipulation der Messungen

Velocity als Versprechen

Velocity ist ein Planungsinstrument, kein Versprechen oder Vertrag. Sie sollte nicht als:

• Garantierte Liefermenge kommuniziert werden
• Unveränderliche Verpflichtung betrachtet werden
• Ziel an sich gesehen werden

Best Practices für die Arbeit mit Velocity

Für einen gesunden Umgang mit Velocity empfehlen sich folgende Praktiken:

Messung und Tracking

• Velocity über mehrere Sprints verfolgen, nicht nur einzelne Sprints betrachten
• Velocity-Trends visualisieren, z.B. mit Velocity Charts
• Kontextfaktoren dokumentieren, die Ausreißer erklären könnten
• Regelmäßig die Schätzskala kalibrieren, um Konsistenz zu gewährleisten

Planung mit Velocity

• Für die Sprint-Planung einen konservativen Ansatz wählen (z.B. 80% der durchschnittlichen Velocity)
• Bei der Release-Planung Puffer für Unsicherheiten einplanen
• Bei neuen Teams vorsichtig mit den ersten Velocity-Werten umgehen
• Velocity als einen von mehreren Faktoren bei Entscheidungen betrachten

Kommunikation

• Stakeholdern den Zweck und die Einschränkungen von Velocity erklären
• Velocity als Planungsinstrument, nicht als Leistungsmetrik kommunizieren
• Transparenz über Faktoren schaffen, die die Velocity beeinflussen
• Prognosen auf Basis von Velocity-Ranges statt einzelner Zahlen präsentieren

Alternative und ergänzende Metriken

Velocity sollte nicht die einzige Metrik sein, die Teams verfolgen. Ergänzende Metriken sind:

• Cycle Time: Zeit von der Aufnahme einer Aufgabe bis zu ihrer Fertigstellung
• Lead Time: Zeit von der Anforderung bis zur Lieferung
• Durchfluss (Throughput): Anzahl der fertiggestellten Items pro Zeiteinheit
• Defect Escape Rate: Anteil der Fehler, die erst nach dem Sprint entdeckt werden
• Team Happiness: Zufriedenheit und Engagement des Teams
• Customer Satisfaction: Zufriedenheit der Stakeholder mit den gelieferten Inkrementen

Velocity in verschiedenen agilen Frameworks

Velocity in Scrum

In Scrum ist Velocity ein wichtiges Planungsinstrument für Sprint Planning und Release Planning. Scrum Teams verwenden häufig Burndown Charts oder Burnup Charts, um den Fortschritt innerhalb eines Sprints zu visualisieren und die Velocity über mehrere Sprints zu verfolgen.

Velocity in Kanban

Reine Kanban-Teams verwenden traditionell keine Story Points und damit auch keine Velocity im klassischen Sinne. Stattdessen konzentrieren sie sich auf Durchfluss, Cycle Time und Work in Progress (WIP). Hybride Scrumban-Ansätze können jedoch Elemente beider Systeme kombinieren.

Velocity in SAFe

Im Scaled Agile Framework (SAFe) wird Velocity sowohl auf Team-Ebene als auch aggregiert auf Programm-Ebene verwendet. SAFe nutzt die Velocity für die PI-Planung (Program Increment Planning) und zur Kapazitätsplanung für mehrere Teams innerhalb eines Agile Release Trains.