Vor einiger Zeit habe ich in den News gelesen, dass das internationale Einheitssystem SI überarbeitet wurde und das Urkilogramm durch Naturkonstanten ersetzt wurde. Diese Nachricht fand ich spannend und Erinnerungen an den Physikunterricht von damals kamen hoch. Heute befasse ich mich mit Kennzahlen, die nicht über SI-Einheiten definiert und alles andere als konstant sind. Dies gab mir den Anlass, die Velocity als Kennzahl aus meiner täglichen Arbeit als Scrum Master zwar nicht neu zu definieren, aber meine Definition davon in einem Blogbeitrag zur erläutern.

Velocity heisst übersetzt so viel wie «Geschwindigkeit». Die Velocity als Kennzahl in einem Scrum-Projekt zeigt auch mehr oder weniger die Geschwindigkeit eines Scrum-Teams an. Ich schreibe «mehr oder weniger», weil die Velocity eine Kennzahl ist, die doch immer wieder Erklärung bedarf.

Die Geschwindigkeit, mit der ich im Auto unterwegs bin, definiert sich als Verhältnis zwischen Weg und Zeit. In einem Scrum-Projekt lässt sich die Geschwindigkeit messen als erledigte Arbeit pro Sprint, also Arbeit pro Zeit. Soweit, so einfach – könnte man meinen. Das Problem ist, dass die geleistete Arbeit eines Scrum-Teams nicht so einfach zu messen ist. Da helfen die SI-Einheiten nicht weiter, auch wenn die physikalische Arbeit als «Joule» genau definiert ist.

Story Points

Also muss eine andere Einheit her, die in das Verhältnis mit der Zeit gesetzt werden kann. Und da gibt es etwas, was Scrum-Teams häufig verwenden: Story Points, kurz SP. Mit Story Points wird die Komplexität von Anforderungen geschätzt. Anstatt einen Zeitaufwand zu prognostizieren, vergleichen Scrum-Teams verschiedene Anforderungen hinsichtlich ihrer Komplexität und vergeben dafür Story Points.

Velocity berechnen

Weil wir die tatsächlich geleistete Arbeit nicht direkt messen können, nehmen wir die Aufwandschätzung der Arbeit  und setzen sie ins Verhältnis mit der dafür investierten Zeit und erhalten so eine Velocity. Nun haben wir eine Definition: SP pro investierte Zeit = Velocity. Wer aber genau mitgelesen hat, bemerkt, dass etwas nicht ganz stimmt. Anstatt Geleistetes zu messen, wird mit dieser Definition Geplantes resp. die Schätzung gemessen. Und trotzdem wende ich genau diese Definition in meinem Alltag an. Warum?

Die Velocity habe ich eingangs in «Geschwindigkeit» übersetzt. Das war ein Fehler, denn die Velocity zeigt nicht, wie «schnell» etwa ein Scrum-Team arbeitet und es ist auch nicht das Ziel der Velocity dies zu tun. Der Sinn und Zweck dieser Kennzahl ist, dass mit der Schätzung der Anforderungen in Story Points geplant werden kann. Und dank der Velocity kann diese Schätzung in Zeit «umgewandelt» werden. Die durchschnittliche Velocity der vergangenen Sprints zusammen mit der Verfügbarkeit des Teams (in Personentagen) ergibt dann eine genaue Kapazität in SP für zukünftige Sprints.

Das klingt schrecklich kompliziert und ist viel aufwändiger als eine klassische Aufwandsschätzung mit einer einfachen Zeiteinheit. Die Schätzung der Komplexität mit Story Points und die Planung anhand der Velocity wiederspiegelt aber die Realität. Zu Beginn eines Projektes können die Anforderungen viel einfacher anhand ihrer Komplexität verglichen werden und dementsprechend Zeitneutral geschätzt werden. Zeitprognosen werden im Verlauf eines Projektes nämlich stark variieren, genauso wie sich die Teamzusammenstellung und die äusseren Einflüsse ändern können.

Weit verbreitet ist die Definition, dass die Velocity besagt, wieviel SP ein Team pro Sprint abarbeiten kann. Ich setzte diese Zahl ins Verhältnis zur tatsächlich investierten Zeit. Dadurch wird verhindert, dass sich die Velocity durch Abwesenheiten von einzelnen Teammitgliedern verfälscht wird. Denn das Verhältnis der Schätzung zur investierten Zeit bleibt unabhängig der Teamgrösse unverändert.

Beispiel

Ich möchte die Berechnung der Velocity anhand eines Beispiels erläutern: Ein Scrum-Team schätzt 10 unterschiedliche Anforderungen und vergibt Story Points für alle Anforderungen. Die Summe der Schätzungen ergibt 27 SP. Während eines Zeitraums von zwei Wochen hat das Scrum-Team alle 10 Anforderungen umgesetzt und dafür total 29.5 Tage investiert. Die Velocity des Teams war in diesem Zeitraum also ungefähr 1.09 (29.5 Tage / 27 SP). Die Velocity sagt nun aus, dass für ein Story Point 1.09 Tage aufgewendet wurden. Nimmt man die durchschnittliche Velocity der vergangenen drei Sprints, kann damit eine genaue Prognose erstellt werden, wie schnell weitere Anforderungen umgesetzt werden.

Fazit

Die Velocity als Kennzahl ist also ein wichtiges Werkzeug für die Planung zukünftiger Arbeiten. Die zeitlichen Schwankungen der Kennzahl sollen auch analysiert werden und ein Scrum-Team sollte bestrebt sein, durch Prozessoptimierung die Kennzahl zu optimieren. Ob ein Team aber absolut gesehen «schnell» oder «langsam» arbeitet, darf aus der Velocity nicht interpretiert werden. Genauso wie bei der neuen Definition des Urkilograms: das Gewicht ändert sich nicht, egal wie man es definiert.