Agiles Management reduziert den Aufwand für die Planung von Projekten und optimiert die  Erstellung wertvoller Produkte und Dienstleistungen für Kunden und Anwender. Organisationen, die neu bei Agile sind, haben jedoch oft Bedenken, wie sie die Leistung ihrer Teams berechenbar machen können. Die Velocity , also die Geschwindigkeit ist eine großartige Messgröße, um den Fortschritt agiler Teams zu messen.

Was ist Velocity?

Einfach gesagt, Velocity ist der Arbeitsaufwand, den ein Team in einer bestimmten Zeit bewältigt. Wie bei einem Burn Down Chart kann die Geschwindigkeit in Personenstunden, Anzahl der Aufgaben, Story Points oder anderen Maßeinheiten gemessen werden. Die Geschwindigkeit eines Scrum Teams ist die Anzahl der in einem Sprint absolvierten Story Points (oder Personenstunden etc.).

Wie misst man Velocity?

Machen wir dazu ein Beispiel:
Ein Team plante, im ersten Sprint 41 Story Points in Angriff zu nehmen. Sie erledigen 28 Story Points und schieben 13 davon in den nächsten Sprint. Also ist ihre Geschwindigkeit 28. Unvollendete Arbeiten zählen nicht zur Velocity des Teams. Bis dahin sagt das nicht viel aus. Wir wissen, dass das Team sein Ziel nicht erreicht hat. Nach einem einzigen Sprint ist die Velocity keine sehr nützliche Metrik für Vorhersagen. Es gibt dem Team daher erst einmal ein Gefühl dafür, wie viel Arbeit es in einem einzigen Sprint leisten kann.

Man muss den Fortschritt über weitere Sprints verfolgen. Nehmen wir weiterhin an, das Team hat im ersten Sprint 28 Story Points, im zweiten Sprint 36, im dritten 28 und im vierten Sprint 30 Story Points abgearbeitet. Ihre durchschnittliche Velocity beträgt dann also 30,5. Dieser Durchschnitt, über nur vier Sprints, ist schon viel nützlicher als der Schnappschuss, den wir nach nur einem Sprint hatten. Es ist leicht vorstellbar, wie wir mit einem Backlog an bereits geschätzten User Stories diese Geschwindigkeit nutzen können, um Vorhersagen zu treffen. Man könnte fundierte Vermutungen darüber anstellen, welche Funktionen wir in den kommenden Versionen bereitstellen können.

Verwendung der Velocity

Die Verwendung von Velocity zur Messung der Produktivität und bei Vorhersagen ist mit einer großzügigen Portion Vorsicht zu genießen. Velocity ist eine geeignete Kennzahl für die Leistung eines Teams. Aber sie enthält nicht alle Kontextinformationen, die man benötigt, um wirklich gute Vorhersagen zu treffen. Dazu müssen Product Owner, ScrumMaster und Entwicklungsteams nach wie vor ihre klugen Köpfe zusammenstecken und ins Detail gehen.

Velocity funktioniert am besten mit langlebigen, stabilen Teams, die viel Erfahrung im gemeinsamen Arbeiten (und Schätzen) haben. Wenn die Mitglieder der Teams häufig wechseln oder unter längeren Abwesenheiten leiden, ist die Geschwindigkeit viel weniger aussagekräftig. Dasselbe gilt, wenn dem Product Backlog User Stories fehlen. Mangelnde Sicherheit über die Zukunft des Produkts kann alarmierend sein, aber es ist auch einer der Vorteile von Agile. Es gibt die Möglichkeit, schnell auf sich ändernde Kundenbedürfnisse zu reagieren und Feedback in Produkte und Dienstleistungen zu integrieren.

Herausforderungenen

Die Messung der Velocity weißt diverse Schwächen auf:

Der Beobachter-Effekt

Der Beobachtereffekt besagt, dass die Beobachtung eines Prozesses dessen Ausgang beeinflusst. Wenn man einem Team sagt, dass ihre Geschwindigkeit gemessen wird, könnte das Team die User Stories und Backlog Items überschätzen, um ihre Geschwindigkeit zu erhöhen. Dies ist besonders gefährlich bei der Arbeit mit Story-Points, da es keine Möglichkeit gibt, die Gültigkeit einer Schätzung zu vergleichen.

Der Streetlight-Effekt

Der Streetlight-Effekt ist unsere menschliche Tendenz, nach Antworten dort zu suchen, wo sie leicht zu finden sind. Beispielsweise kann man produzierte Codezeilen zählen. Dies sagt aber nichts über die Qualität der Anwendung, die Funktionalität oder gar die Effektivität aus.

Alternativen

Um diese Effekte weitestgehend zu vermeiden, gibt es Alternative Metriken. Diese messen den tatsächlichen Output und nicht die beitragenden Faktoren

Gelieferter Wert

Im Artikel „User Stories richtig schätzen“ haben wir uns bereits mit dem Thema der Nutzenschätzung und ihrem Wert auseinandergesetzt. Jedem Backlog Item sollte einen Wert zugeordnet werden, der seine Wirkung für die Stakeholder darstellt. Dies kann mit einem tatsächlichen Geldbetrag oder einer beliebigen Zahl wiedergespiegel werden. Am Ende eines jeden Sprints entsteht somit ein Wert, der darstellt, Ihnen sagt, wie viel Wert das Team geliefert hat. Diese Kennzahl misst nicht die Leistung, sondern die Wirkung. Im Idealfall wird der Product Owner höherwertige Artikel an die Spitze des Backlogs setzen, so dass jeder Sprint den maximal möglichen Wert liefert.
In einem endlichen Projekt mit einem definitiven Ende, werden die Sprints einen sehr hohen Wert haben und allmählich immer weniger Wert liefern. Irgendwann werden die Entwicklungskosten den potenziellen Wert eines weiteren Sprints übersteigen. Das ist in der Regel ein guter Zeitpunkt für das Team, auf ein neues Produkt umzusteigen.

Pünktliche Lieferung

Ein Grund warum agile Transformation in Unternehmen scheitert, ist das man Kunden oft keine konkreten Liefertermine nennen kann. Anstatt die Geschwindigkeit zu messen, sollte man Teams am Zeitpunkt der Fertigstellung ihrer vorausgesagten Items bemessen. Hierzu kann man eine Punktebewertung einführen. Je früher ein Team liefert desto mehr Punkte erhält das Team für den jeweiligen Sprint.

Was wir also messen, ist der Wert, der dem Kunden geliefert wird, und die pünktliche Lieferung. Dies sind die einzigen beiden echten Metriken, mit denen Geld verdient wird.

Einen Überblick zur Serie Scrum Basics findest du hier: Scrum Basics: Alles auf einen Blick