Velocity-Tracking misst die Menge an Arbeit, die ein Produktentwicklungsteam pro Sprint erledigt, ausgedrückt in Story Points, und nutzt diesen historischen Durchschnitt, um die zukünftige Lieferkapazität zu prognostizieren. Es ist das primäre Instrument von Product Ops für eine realistische Release-Planung und das Management von Stakeholder-Erwartungen.
?
Wie wird die Velocity gemessen und was sagt sie Teams aus?
Velocity = Gesamtanzahl der in einem Sprint abgeschlossenen Story Points. Sie ist nur als gleitender Durchschnitt aussagekräftig, typischerweise berechnet über die letzten 3–6 Sprints, um Ausreißer (Urlaubswochen, Teamunterbrechungen) zu glätten. Ein Team mit einer durchschnittlichen Velocity von 40 Punkten über 6 Sprints sollte Sprint-Verpflichtungen von etwa 35–40 Punkten planen, wobei das untere Ende realistischer ist, wenn die Unsicherheit hoch ist. Velocity ist ein Planungstool auf Teamebene – sie sollte niemals verwendet werden, um Teams zu vergleichen oder die Leistung einzelner Ingenieure zu bewerten. Story Points sind relative Größenordnungs-Schätzungen, keine Zeitschätzungen, und die Punkteskala eines Teams ist nur innerhalb dieses Teams aussagekräftig.
?
Was verursacht Velocity-Variabilität und wie sollte Product Ops darauf reagieren?
Die Velocity variiert naturgemäß von Sprint zu Sprint um 15–25% aufgrund normaler Faktoren: Änderungen in der Teamzusammensetzung, unerwartete Komplexität in der technischen Implementierung, Urlaubs- und Krankheitszeiten. Besorgniserregende Variabilitätssignale, die eine Untersuchung erfordern: konsistenter Abwärtstrend über mehrere Sprints (kann auf akkumulierende technische Schulden, eine wachsende Scope-Creep-Kultur oder Probleme mit dem Teamwohlbefinden hinweisen); plötzliche und anhaltende Rückgänge nach einem Teamwechsel (Onboarding-Verzögerungen durch neue Teammitglieder sind zu erwarten, sollten sich aber innerhalb von 2–3 Sprints erholen); Velocity-Inflation (Teams blähen Story-Point-Schätzungen zunehmend auf, um Velocity-Erwartungen zu „erfüllen“ – dies macht die Planung bedeutungslos). Product Ops überwacht Velocity-Trends und markiert Anomalien zur Diskussion in Retrospektiven.
?
Wie wird die Velocity zur Prognose von Release-Terminen verwendet?
Die Prognose von Release-Terminen mit Velocity ist eine Monte-Carlo-Simulation, keine einfache Arithmetik. Der Monte-Carlo-Ansatz: Erstellen Sie eine Wahrscheinlichkeitsverteilung aus der historischen Velocity-Verteilung des Teams (nicht nur dem Durchschnitt), führen Sie 10.000 Simulationen zur Fertigstellung des verbleibenden Backlogs unter Verwendung zufällig ausgewählter Velocities aus dieser Verteilung durch und lesen Sie die Wahrscheinlichkeitsergebnisse ab. Dies erzeugt eine Prognose mit Konfidenzintervallen: „Es besteht eine 85%ige Wahrscheinlichkeit, dass das Feature bis Sprint 24 ausgeliefert wird.“ Dies ist ehrlicher als „wir werden in Sprint 22 ausliefern“ – Stakeholder erhalten einen realistischen Wahrscheinlichkeitsbereich anstelle einer einzelnen Punktschätzung, die sich oft als falsch erweist. Product Ops erstellt und pflegt das Release-Prognosemodell, aktualisiert es wöchentlich und präsentiert der Führungsebene Prognosen auf Basis von Konfidenzintervallen.
Wissens-Challenge
Velocity-Tracking gemeistert? Versuchen Sie nun, das verwandte 5-Buchstaben-Wort zu erraten!
Tippen oder Tastatur benutzen