Volatile Velocity, stark unterschiedliche Mengen abgeschlossener Arbeit von einem Sprint zum nächsten, untergräbt den Prognosewert, den Velocity eigentlich liefern soll. Bevor zu Stabilisierungstaktiken gegriffen wird, lohnt es sich zu verstehen, dass Velocity-Schwankungen meist ein Symptom sind, und das Symptom zu behandeln, ohne die zugrunde liegende Ursache zu adressieren, selten dauerhafte Stabilität erzeugt.
Die üblichen Ursachen, ungefähr nach Häufigkeit geordnet
Inkonsistente Schätzung ist die häufigste Ursache, und selten, weil das Team im absoluten Sinn schlecht schätzt: Es geht darum, dass Schätzkriterien über die Zeit driften, oder inkonsistent auf unterschiedliche Arbeitstypen angewendet werden, oder verschiedene Teammitglieder implizit unterschiedliche mentale Skalen für dieselben Zahlen nutzen. Eine "5", geschätzt von einer Person, und eine "5", geschätzt von einer anderen, sind nicht zwangsläufig vergleichbar, wenn sie sich nie explizit aneinander kalibriert haben.
Schlecht bemessene Backlog-Elemente sind die zweithäufigste Ursache. Zu große Elemente tragen mehr Schätzunsicherheit, und wenn eine Handvoll übergroßer Elemente im selben Sprint landet, schwankt die Velocity mit dem Ausgang genau dieser wenigen Elemente, statt den tatsächlichen typischen Output des Teams widerzuspiegeln. Arbeit konsequent in kleinere Elemente zu teilen, reduziert die Varianz, die eine einzelne falsche Schätzung beiträgt.
Nicht berücksichtigte Unterbrechungen (Produktionsvorfälle, dringende ungeplante Anfragen, Kontextwechsel zu anderer Arbeit) fressen Kapazität auf eine Weise, die im Plan nicht auftaucht, aber definitiv im Ergebnis. Sprints, die auf dem Papier identisch aussehen, können je nach Menge gelandeter ungeplanter Arbeit sehr unterschiedliche tatsächlich verfügbare Kapazität haben.
Veränderungen in der Teamzusammensetzung (jemand im Urlaub, jemand Neues, noch nicht auf voller Produktivität, ein Teammitglied für einen Teil des Sprints zu einer anderen Initiative abgezogen) beeinflussen die verfügbare Kapazität direkt, auf eine Weise, die eine aus der nominellen Teamgröße berechnete Velocity-Zahl nicht erfasst.
Was Velocity tatsächlich stabilisiert
Schätzung explizit und regelmäßig kalibrieren, nicht nur einmal bei der ersten Teambildung. Eine kurze, wiederkehrende Praxis, gemeinsam ein paar historische Elemente zu schätzen und Uneinigkeiten zu besprechen, verhindert, dass die geteilte Skala des Teams über die Zeit still auseinanderdriftet.
Ungeplante Arbeit separat verfolgen und berücksichtigen, statt sie still in die geplante Kapazität fressen zu lassen, ohne dass sie irgendwo sichtbar wird. Teams, die das Verhältnis von geplanter zu ungeplanter Arbeit über mehrere Sprints messen, können künftige Sprints mit einem realistischen Puffer planen, statt jedes Mal vom selben Muster überrascht zu werden.
Auf eine konsistente Bandbreite an Elementgrößen zielen, alles ungewöhnlich Große aktiv aufteilen, bevor es in einen Sprint kommt, statt übergroße Elemente zu akzeptieren und zu hoffen, die Schätzung halte.
Velocity über einen gleitenden Durchschnitt mehrerer Sprints betrachten, nicht sprintweise. Etwas Volatilität ist inhärent und kein Zeichen eines Problems: Ein gleitender Durchschnitt über drei oder fünf Sprints glättet normales Rauschen und zeigt echte Trends, während Einzelsprint-Vergleiche oft nur statistisches Rauschen zu einer scheinbaren Krise verstärken.
Stabile Velocity ist nicht wirklich das Ziel an sich. Sie ist das Nebenprodukt eines Teams mit konsistenten Schätzgewohnheiten, angemessen bemessener Arbeit und Sichtbarkeit darüber, was tatsächlich seine Kapazität frisst. Die Zahl direkt zu jagen, ohne zu adressieren, was ihre Instabilität antreibt, funktioniert tendenziell nicht.