Für agile Projekte ist die → Velocity eine team-spezifische Angabe über die Summe fertiggestellter “Arbeit” innerhalb eines Intervalls. Ein trivial einfacher → „KPI“ mit mächtiger → Hebel-Wirkung – positiv, aber auch negativ.
Richtig angewandt ermöglicht die Velocity eine zuverlässige Release-Planung, Steuerung und Controlling. Feste Liefertermine und der „agile Festpreis“ werden möglich. Wird die Velocity jedoch zweckentfremdet, fehlerhaft gelebt oder Schindluder damit getrieben, ergeben sich erhebliche, manchmal nicht mehr zu reparierende Nachteile.
Die Velocity, ungünstig oder falsch genutzt, nachfolgend als → Agile Smell:
-
Die Velocity ist scheinbar konstant, obwohl es besser oder schlechter läuft (danke an Daniel Hommel [1])
Smell:
Das Team hat über viele Sprints hinweg die selbe Velocity, obwohl sich alle einig sind, dass man besser (oder schlechter) wurde.Mögliche Ursache:
Keine stabile Referenz für Schätzungen.Genauer:
Was ein → Story Point (eine T-Shirt Größe oder whatever) für das Team bedeutet ist über die Zeit nicht konstant. Wird das Team besser oder schlechter passt es seine Schätzungen entsprechend an. Veränderungen der Team-Performance werden hinter einer Schätzungsdeflation (oder -Inflation) versteckt. Eigentlich passiert hinten herum genau das, was Story Points im Gegensatz zu Stundenschätzungen verbessern sollen („Ich kann das nach der letzten Schulung besser, also ist es jetzt weniger Aufwand!“)…Abhilfe:
Stabile Referenz einführen.Daniel: „Habe hiermit persönlich bei einem Team ziemliche Kopfschmerzen, weil das Team denkt es macht alles richtig… Reicht ja für Forecasts! :-)“
-
Velocity wird nicht für Release Burndown bzw. Release-Planung, Steuerung und Controlling genutzt
Smell:
Kurz vor dem mit dem Kunden vereinbarten Liefertermin („deadline“) stellt der Product Owner (PO) „völlig überrascht“ fest, dass dieser Termin nicht einzuhalten istMögliche Ursache:
Der PO hat noch nicht gelernt mit Hilfe der Velocity seine Release-Planung aktiv zu steuern. Er nutzt diese nur im Sinne von → „Cargo Cult“, sie ist im „lästig“.Abhilfe:
Die Möglichkeiten rund um die Velocity aktiv (kennen-) lernen und engagiert für Release-Planung, Steuerung und Controlling nutzen (siehe z.B. → Anregungen aus und für die Praxis – Product Backlog “Priorisierungen”). - Missbrauch der team-spezifischen Velocity um „Wettbewerb“ zwischen den Teams zu erzeugen
- Velocity ohne Berücksichtigung der Mitarbeiter-Verfügbarkeiten („normierte Velocity“ wird nicht benutzt)
- Velocity nicht up-to-date
- Velocity-Änderungen werden nicht für Feedback und als Chance für Verbesserungen und zum Lernen genutzt (kein → „inspect & adapt“)
- Velocity-Verschlechterung wird vom Management für „Druck-Erhöhung“ missbraucht
Diese Übersicht ist wie immer → „work in progress“…
Welche Erfahrungen hast Du bei der Anwendung der Velocity in euren Projekten?
CU
@ Boeffi .net aktualisiert am 24.05.2018
[1]
Daniel Hommel hatte mir freundlicherweise einige Anregungen zu seinen „Agile Smells“-Erfahrungen gemailt. Neben seinen Anmerkungen zur „Velocity“ auch zu → „DoD“ und „Timebox (im Sinne eines ‚Spike‘ im Sprint)“, die ich demnächst ebenfalls gern veröffentliche.
Infos zu Daniel erhälst Du z.B. unter:
→ https://www.scrumalliance.com/site_search?q=dhommel
→ dhommel.net