Was ist eigentlich Velocity?

„Velocity“ bedeutet im Deutschen „Geschwindigkeit“. Der Begriff Velocity hat aber im Zusammenhang mit Scrum und agilem Management längst eine weitere Bedeutung bekommen. Alex Kudinov möchte mit seinem Artikel auf www.scrum.org einen Blick auf Team Velocity im Scrum werfen und definieren, was mit diesem neuen Terminus alles gemeint ist. Im Folgenden fassen wir seinen Beitrag für Sie zusammen.

Velocity wird im Zusammenhang mit Scrum in unterschiedlichem Kontext verwendet. Am häufigsten wird Velocity im Sinne einer Maßeinheit genutzt, mit der man angeben kann, wie schnell ein Team Ergebnisse liefert. Das ist im Grunde eine sehr gute Definition. Selbstverständlich folgt darauf die Frage, was eigentlich gemessen wird und wie. Und es stellt sich auch die Frage, warum übehaupt gemessen wird. Scrum.org erkennt Velocity als eine Art zusätzliche Verfahrensweise an. Im Scrum gibt es keine allgemeingültige Definition davon, wie die Fähigkeit eines Teams zu messen ist, um für den Auftraggeber einen Mehrwert zu liefern. Scrum ist dafür bekannt, dass es offen für eine Vielzahl an Verfahrensweisen ist, es kommt vor allem darauf an, eine Technik zu finden, die für das jeweilige Team und dessen Aufgaben und Bedürfnisse passend ist. Velocity ist eine dieser flexiblen Verfahrensweisen.

Schlagen Sie im Scrum-Wörterbuch nach, wird Velocity so definiert: Es ist eine optionale, aber oft eingesetzte Angabe der durchschnittlichen Menge an Product Backlogs, die im Laufe eines Sprints von einem Scrum-Team in ein Produktinkrement verwandelt wird, welches wiederum vom Entwicklerteam zur Verwendung innerhalb des Scrum-Teams überwacht wird. Das klingt nicht eben selbsterklärend. Daher versucht Alex Kudinov es herunterzubrechen und etwas tiefer ins Thema einzusteigen. Zunächst muss man sich ins Gedächtnis rufen, dass das primäre Ziel jedes Scrum Teams das Generieren von Mehrwert für den Kunden ist. Es entsteht ein Done Increment am Ende jedes Sprints. Jedes Scrum Team verwandelt also Product Backlog Items in wertvolle Done Increments. Dies kann dann vom Product Owner an den Kunden übergeben werden.

Es gibt verschiedene Wege um zu messen, wie viele Product Backlogs in Done Increments verwandelt werden konnten. Viele Teams benutzen dazu sogenannte Story Points. Diese Vorgehensweise ist vielfach beschrieben und noch viel häufiger erprobt worden. Man muss sich allerdings immer vor Augen halten, dass Story Points immer sehr abstrakt sind. Sie hängen stark davon ab, wie das Team die Einheiten seiner Arbeit unterteilt und sie sind daher sehr projektspezifisch. Auf keinen Fall können Story Points als Maßeinheit für die Leistungsfähigkeit oder Produktivität des Teams eingesetzt werden, auch wenn dieses Missverständnis oft aufkommt. Um zu messen, wie viel Arbeit ein Team bereits geleistet hat, gibt es andere Möglichkeiten. Einige Teams erfassen Stunden. Das hat Nachteile, auf die Alex Kudinov in seinem Artikel nicht weiter eingeht. Wieder andere Teams zählen ganz einfach die Anzahl an Product Backlogs, die in Done Increments verwandelt wurden. Letztere Methode ist wahrscheinlich in Teams, die Kanban anwenden, die beliebteste Methode.

Es ist im Grunde gleich, welchen Weg ein Team wählt, solange das Team hinter der Entscheidung steht und einen für die eigene Vorgehensweise guten Weg gefunden hat. Den eigenen Erfolg zu messen, ist wichtig und kann nicht von oben auferlegt werden. Zudem bedeutet dies, dass Teams nicht miteinander verglichen werden können, denn jedes Team muss seinen eigenen Weg zum Messen des Erfolgs finden. Im Scrum wird großen Wert daraufgelegt, dass eine Messmethode „vom Team fürs Team“ angewendet wird und nicht von jemand anderem. Das Messen von Velocity ist laut Alex Kudinov für einen einzigen Zweck von Bedeutung: dafür, als Input in der Sprintplanung zu dienen. Laut Scrum Wörterbuch müssen folgende Größen in die Sprintplanung einfließen: der Product Backlog, das letzte Product Increment, die geschätzte Teamkapazität für den kommenden Sprint und die vorherige Leistungsfähigkeit des Entwicklerteams. Diese letzte Zutat, die Leistungsfähigkeit des Entwicklerteams während ihrer vorangegangenen Aufgaben, kann als die Velocity betrachtet werden, muss aber nicht – oder zumindest nicht ausschließlich. Hier kann jede Art von Maßeinheit verwendet werden, je nachdem, wofür sich das jeweilige Team entscheidet. Alex Kudinov erinnert hier noch einmal daran, dass Scrum nur ein Rahmen ist, in dem alle möglichen Arten von Verfahrensweisen angewendet werden können.  

Haben Sie schon davon gehört, dass das Ziel von Scrum lautet „doppelt so viel Arbeit in der Hälfte der Zeit“ zu leisten? Hat das nicht im bekannten Buch von Jeff Sutherland gestanden? Viele haben schon davon gehört und fragen erfahrene Scrum Master immer wieder danach. Schließlich klingt das verlockend. Nicht wahr? Alex Kudinov betont, dass ein guter Scrum Master da ist, um seine Teams zu coachen und allen dabei zu helfen, Scrum bestmöglich einzusetzen. Das berühmte Zitat von Jeff Sutherland verstehen leider viele falsch oder zumindest zu wörtlich. Scrum ist nicht dazu da, alles viermal zu schnell zu machen. Scrum ist nur dazu da, sich auf das Ergebnis, auf den Output und auf den tatsächlich kreierten Mehrwert, zu konzentrieren. Durch kontinuierliches Anpassen, Hinterfragen und vollkommene Transparenz soll auf die effektivste Weise gearbeitet werden. Ob das nun die Hälfte oder ein Viertel der Zeit einspart, ist nebensächlich. Es kommt darauf an, die Aufgabe so schnell und so gut wie möglich zu erledigen, ohne sich mit Fehlern, Irrwegen, Bürokratie und Prozeduren aufzuhalten. Velocity ist in diesem Zusammenhang nicht geeignet, um zu messen, wie wertvoll Ihr Endprodukt wirklich ist. Dafür müssen andere Methoden eingesetzt werden. Velocity kann aber auf dem Weg zum Erfolg durchaus ein Hilfsmittel sein, wenn Ihre Teams sich selbst bei der Arbeit einschätzen wollen.