4.7 min readPublished On: 21. Mai 2021By Categories: Bücher, Wissen

Weißt Du was Velocity ist?

Ob es auf dem Mond eine Fahrradstadt gibt?

Vielleicht denkt der eine oder andere Fahrradbegeisterte beim Begriff Velocity „Ist doch glasklar. Velo bedeutet Fahrrad, City bedeutet Stadt, also bedeutet Velocity Fahrradstadt“. Und tatsächlich hat er mit dieser Idee nicht ganz unrecht. Denn laut meiner Internetrecherche gibt es das ein oder andere Unternehmen aus dem Fahrradbereich, das Velocity heißt. Mit hoher Wahrscheinlichkeit hätte keines dieser Unternehmen etwas gegen mehr Fahrräder in Städten.

Doch wenn der Autor

Kenneth S. Rubin: Essential Scrum. Umfassendes Scrum-Wissen aus der Praxis

über Velocity schreibt, hat er keineswegs Fahrräder im Kopf, sondern eine Kennzahl für Scrum- Teams.

Was für eine Kennzahl ist Velocity?

Jede Aufgabe in einem Sprint hat Velocitypunkte.

Mit der Velocity wird die Entwicklungsgeschwindigkeit eines Teams gemessen. Jede Aufgabe in einem Sprint hat eine bestimmte Anzahl an Velocity-Punkten. Die Anzahl der Punkte ist von der Schwierigkeit der Aufgabe abhängig. Eine leichte Aufgabe hat eine Velocity-Maßeinheit von 1, eine schwierige Aufgabe eine Velocity-Maßeinheit von 5 oder mehr.

Ein Scrum-Team erledigt seine Arbeit in festgelegten Zeitfenstern namens Sprints, die je nach Team zwischen 2 und 4 Wochen dauern. In dieser Zeit arbeitet ein Scrum-Team an den Aufgaben, die zu Beginn des Sprints definiert wurden. Wenn ein Team in einem Sprint 3 Aufgaben erledigt, die jeweils 3 Velocity-Punkte haben, hat es am Ende des Sprints eine Velocity von 9. Wenn es in dieser Zeit 15 Aufgaben mit je einem Velocity-Punkt schafft, liegt die Velocity bei 15 Punkten.

Ein frisch zusammengestelltes Scrum-Team hat in seinen ersten Sprints in der Regel eine geringe Velocity, die von Sprint zu Sprint leicht schwankt und sich in der Langzeitbetrachtung nach oben entwickelt. Ein richtig gut eingespieltes Scrum-Team dagegen hat in der Regel eine stabile Velocity.

Warum schwankt die Velocity bei frischen Teams?

Ich bin ziemlich gut mit Zahlen und Du?

Stell Dir an dieser Stelle bitte ein frisch zusammengestelltes Scrum-Team vor, das vor dem ersten Sprint keine ausgiebigen Teambuilding-Maßnahmen durchlaufen hat. Die Team-Mitglieder haben noch nie zuvor miteinander gearbeitet und kennen sich nur oberflächlich. Jeder im Team kennt nur seine eigenen Stärken und Schwächen.

Bei der Sprint-Planung kann also jeder im Team nur seine eigenen Ressourcen einschätzen, nicht aber die Ressourcen und Fähigkeiten der anderen Teammitglieder.

  • Jedes Mitglied weiß, welche Aufgaben ihm leichtfallen und welche nicht.
  • Es hat keine Ahnung, wie lange die anderen Team-Mitglieder für eine bestimmte Aufgabe brauchen.
  • Kein Teammitglied weiß, welche Aufgaben schnell zu erledigen sind, und welche Aufgaben lange dauern werden.
  • Die Kommunikation im Team ist noch nicht eingespielt, und daher kommt es häufiger zu Missverständnissen bei der Aufgabenabstimmung.

Aus diesem Grund liegen die Teammitglieder bei der ersten Sprint-Planung meistens völlig daneben und planen daher zu wenige oder zu viele Aufgaben für den Sprint ein.

Zu Beginn des zweiten Sprints kennt sich das Team schon etwas besser. Ist der erste Sprint gut gelaufen, wird das Team mehr Aufgaben einplanen. Ist der erste Sprint nicht gut gelaufen, wird das Team weniger Aufgaben einplanen.

Warum ist die Velocity bei eingespielten Teams stabil?

Die Aufgabe ist einfach.

Ein gut eingespieltes Team kennt die Stärken und Schwächen aller Teammitglieder und weiß ganz genau, welche anderen Ressourcen ihm während eines Sprints zur Verfügung stehen. Es weiß aus Erfahrung, welche Aufgaben es schnell erledigt und welche Aufgaben lange dauern und kann daher zuverlässig die Velocity aller Aufgaben planen.

Ein Team, das eine Velocity von 25 hat, weiß, dass es mindestens 1 Aufgabe mit 25 Velocitypunkten oder maximal 25 Aufgaben mit jeweils einem Velocitypunkt in einem Sprint schafft. Das Team würde nie auf die Idee kommen, 10 Aufgaben mit jeweils 5 Velocitypunkten für einen Sprint einzuplanen, weil es weiß, dass die eigene Velocity bei 25 und nicht bei 50 liegt.

In eingespielten Teams schwankt die Velocity in der Regel nur, wenn es weniger Ressourcen als üblich hat. So fällt die Velocity für einen Sprint z. B. dann von 25 auf 20, weil ein Teammitglied im Urlaub ist.

Fazit

Warum ist es gut, wenn die Velocity nicht steigt?

Die Velocity bemisst die Entwicklungsgeschwindigkeit eines Scrum-Teams. Für den Product Owner in einem Scrum-Team kann es durchaus eine Herausforderung sein, dem restlichen Unternehmen, das nicht nach Scrum organisiert ist, die Sache mit der Velocity zu erklären, weil sie außergewöhnlich ist. Sie ist eine außergewöhnliche Kennzahl, weil ein gutes Scrum Team sich nicht durch eine dauerhaft steigende Velocity, sondern durch eine stabile Velocity auszeichnet.

UPDATE 28.10.2021: Im Gegensatz zu anderen Kennzahlen wird die Velocity also nicht genutzt um einem Team immer höhere Ziele zu setzte, sondern ehr das Gegenteil.

„Das Messen der Velocity soll verhindern, dass sich das Team übernimmt.“

Rini van Solingen: Agile. Ein schönes Buch darüber, wie eine Organisation gesund, flexibel und fit wird, voller Tipps, Fallstricke und Praxiserfahrung, S.25.

Von einem Team eine von Sprint zu Sprint steigende Velocity zu erwarten, wäre in etwa so, wie sich vor einen Drucker zu stellen, der eine Druckgeschwindigkeit von 20 Seiten in der Minute hat und von diesem zu verlangen, dass er nun 25 Seiten pro Minuten druckt. Jeder Mensch weiß, dass 25 und mehr Druckseiten pro Minuten möglich sind. Doch dafür braucht es halt einen anderen Drucker mit anderen technischen Voraussetzungen. Genau so ist es mit der Velocity. Ein Scrum-Team kann seine Velocity in einem gewissen Rahmen dauerhaft erhöhen, wenn es mehr Ressourcen zur Verfügung hat.