Die Velocity, oder der Durchsatz, ist eine der bekanntesten agilen Metriken. Sie ergibt sich aus der Addition aller Story Points der vom Scrum-Team in einem Sprint gelieferten Storys. De facto zeigt sie also die Produktivität eines Teams innerhalb eines Sprints und wird in der Praxis anhand des Velocity-Charts visualisiert. Diese einfache und leicht verständliche Kennzahl hat vor allem zwei Zwecke: Sie soll Feedback-Instrument sein, anhand dessen das Team seine Lieferfähigkeit beurteilen und verbessern kann. Richtig angewandt wird sie außerdem zu einem wesentlichen Hilfsmittel im Release- und Sprintplanning. Eine zweckentfremdete Anwendung der Velocity führt hingegen zu schädlichem Verhalten, das weder dem Team noch dem Unternehmen dienlich ist. Vier dieser Fallstricke, die uns in der Praxis begegnen können, möchte ich Ihnen vorstellen.
Als Kennzahl zeigt die Team-Velocity die Menge der in einem Sprint fertiggestellten Funktionalitäten (gemessen in Story Points). Sie misst also die Produktivität (=Output) des Teams. Eine Aussage über den gelieferten Wert (=Outcome) können wir aus der Velocity NICHT ableiten. Ein Beispiel: Eine User Story mit der geschätzten Größe 3 könnte einen höheren Wert für den Nutzer liefern als eine User Story der Größe 8. Letztere wird die Velocity jedoch stärker erhöhen als erstere.
Ich gebe Ihnen gerne ein praktisches Beispiel. Stellen Sie sich vor, Sie müssten zwei Datenbanken aktualisieren. Die erste wird vom Nutzer eher selten angesprochen, muss aber manuell aktualisiert werden. Diese Story schätzen Sie mit 8 Story Points. Bei der zweiten Datenbank hingegen, die oft vom Nutzer gebraucht wird und dadurch einen höheren Wert für ihn oder sie hat, kann die Aktualisierung automatisiert stattfinden. Daher ordnen sie dieser Story lediglich den Wert 3 zu, obwohl sie für den Nutzer einen höheren Wert hat.
Für die Leistungsbeurteilung eines Teams ist die Velocity also nur bedingt geeignet. In den kommenden Blog-Beiträgen werde ich Ihnen weitere Metriken vorstellen, welche stärker auf die Qualitätsbeurteilung des gelieferten Produktes abzielen und für eine Leistungsbeurteilung passender sind.
Manager und Managerinnen haben ein natürliches Interesse daran, dass ein Team seine Produktivität kontinuierlich steigert. In der Praxis können wir beobachten, dass Manager und Managerinnen mit einem traditionellen Führungsverständnis sich manchmal dazu verleiten lassen, die (Über-)Steigerung der Produktivität als Teamziel vorzugeben.
Werden Teams nach ihrer Velocity beurteilt, tritt aber folgendes Phänomen auf: Die Schätzungen der User Storys steigen inflationär. Höhere Schätzung = höhere Velocity = bessere Zielerreichung. In der Konsequenz wird die Datenbasis des Unternehmens verfälscht und unbrauchbar. Im schlimmsten Fall wird das Team beginnen „Kurven zu schneiden“, um mehr „fertig“ zu bekommen.
Damit will ich nicht sagen, dass sich ein Team keine ambitionierten Ziele setzen sollte. Im Gegenteil: Ehrgeizige Ziele spornen an. Ein Missbrauch der Velocity als Leistungsmaßstab wird jedoch negative Konsequenzen für das Team und die Organisation als Ganzes nach sich ziehen.
Teams, deren Mitglieder ein ähnliches Skill-Set besitzen, sollten auch eine ähnliche Velocity aufweisen. Oder nicht?
Nicht zwingend! Die Velocity wird durch die geschätzten Größen der einzelnen User Storys beeinflusst. Diese Größenschätzungen sind 1.) relativ und 2.) subjektiv. Das bedeutet: Zwei Teams werden die gleiche User Story mit hoher Wahrscheinlichkeit unterschiedlich groß einschätzen. Ein Vergleich von Teams hinsichtlich ihrer Velocity kann demnach nicht zielführend sein.
Leerlauf ist eine Voraussetzung für kontinuierlich hohe Produktivität. Studien zeigen, dass die Arbeitsleistung von Menschen bei einer Auslastung von mehr als 80 % rapide abfällt. Wir kennen ein ähnliches Szenario aus unserem Alltag: Was passiert, wenn wir an einem PC oder Laptop sitzen, dessen Arbeitsspeicher unter Volllast arbeitet? Das Gerät wir unerträglich langsam. Bei Menschen verhält es sich ähnlich. Durchlaufzeiten werden länger und auch die Qualität leidet unter der (zu) hohen Auslastung. Planen Sie daher ausreichend Zeit für nicht-produktive Arbeiten, wie beispielsweise Trainings, Problemlösungen oder das Gespräch in der Kaffeeküche.
Welche Erfahrungen haben Sie mit der Velocity als Kennzahl machen können? Ich freue mich über Ihre Kommentare und Ihr Feedback. Falls Sie mehr über Velocity, Story Points oder agiles Schätzen erfahren möchten, lade ich Sie herzlich zu meinem Remote-Training Product Owner powered by bg vom 4. bis 6. Mai 2021 ein.
Titelbild: © Lindsay Henwood, Unsplash License