Jede Produktentwicklung ist ein einmaliges und neues Vorhaben. Das bedeutet jedoch auch, dass agile Teams mit jedem Produkt neues Terrain betreten müssen. Zudem muss sich das Entwicklungsteam von Produkt zu Produkt neu einspielen. Auch wenn agile Vorgehensweisen dabei eine wertvolle Unterstützung bieten, bedeutet jedes neue Produkt somit eine große Herausforderung in puncto Planbarkeit. Verlässliche Referenz- und Erfahrungswerte fehlen. Schätzungen zur Leistungsfähigkeit des Teams werden somit erschwert.
Eine Hilfe in diesem Dilemma bietet die Velocity, da sie nicht nur hilfreiche Auskünfte zur Teamleistung gibt, sondern vor allem Hinweise zu Hindernissen und Störfaktoren.
Doch wie genau wird die Velocity berechnet? Welche Erkenntnisse lassen sich aus dem Velocity-Wert des Teams ziehen? Wie sollte die Velocity im agilen Kontext genutzt werden und wie besser nicht? ­– Fragen, auf die dieser Beitrag eine Antwort bietet.

Kurz erklärt: User Story, Story Points und Velocity

Wie der Name bereits sagt, beschreibt die Velocity bzw. der Velocity-Faktor die Schnelligkeit bzw. Leistungsfähigkeit von Entwicklungsteams oder genauer gesagt das Arbeitspensum, das das Team im Lauf eines Sprints (ein fest definierter Zeitabschnitt, meist mit einer Dauer von zwei oder vier Wochen) absolvieren kann. Damit dies gelingt, müssen Product Owner bzw.  Scrum Master im Verlauf des Sprints die Story Points addieren, die das Team durch alle erledigten User Stories gesammelt hat. Als User Story werden im agilen Arbeitskontext die einzelnen zu erreichenden Software- bzw. Produkt-Anforderungen bezeichnet, denen wiederum je nach Aufwand Story Points nach einem festen Schema zugeteilt werden.

Ein Beispiel:

• Story A (Anwenderzählung): 3 Story Points
• Story B (Registrierungsformular): 5 Story Points
• Story C (Produktauswahl im Webshop): 8 Story Points

Am Ende des Sprints steht fest, dass Story A und Story C komplett erledigt wurden, Story B allerdings nur zum Teil geschafft wurde und somit als unerledigt gezählt werden muss.
Das Team hat somit in diesem Sprint eine Velocity von 11 Story Points erreicht.

Um die Velocity grafisch darzustellen, werden in einem Diagramm die aufeinander folgenden Sprints in der X-Achse eingetragen und die Story Points in der Y-Achse. Dadurch wird in der langfristigen Betrachtung die Performance des Teams sichtbar.
Zudem ist es außerdem möglich, die Velocity durch erledigte Stories pro Sprint zu erfassen.

Wie rund läuft das Team? Die Velocity als “Fitnessindikator” für Development Teams

Für Scrum Master ist Velocity weit mehr als ein nettes Zahlenspiel. Richtig eingesetzt kann die Velocity wertvolle Hinweise für einen besseren, weil produktiveren und nachhaltigeren Projektfortschritt bieten:

• Hinweise zur Teamdynamik: Vor allem am Beginn eines Projektes durchlaufen die nicht selten neu zusammengestellten Entwicklungsteams verschiedene Phasen der Teamentwicklung. Es braucht Zeit, bis sich das Team aufeinander und auf die neuen Aufgaben einspielt. Rückschritte und Irritationen sind in dieser Zeit ebenso normal, wie bei späteren Störungen im Projektverlauf, z. B. durch Veränderung der Rahmenbedingungen oder einen personellen Wechsel. Die Velocity kann dabei einen wertvollen Hinweis zur Dynamik und Leistungsfähigkeit des Entwicklungsteams bieten, sollte dabei allerdings nicht zu kurzfristig interpretiert werden.
• Reifesteigerung im Team: Die Velocity kann in agilen Teams zu einem wertvollen Feedbackinstrument werden, das dem Entwicklungsteam eine realistischere Einschätzung der eigenen Produktivität ermöglicht. Nimmt sich das Team beispielsweise immer wieder zu viele oder zu anspruchsvolle Aufgaben vor, sodass im Verlauf der Sprints immer wieder User Stories nicht erfüllt werden und die Velocity sinkt, so kann dies dem Team helfen, das eigene Leistungspensum besser einzuschätzen und belastbarere Schätzungen abzugeben.
• Erkennen von Störfaktoren: Bei der Kommunikation „nach außen“ bietet die Velocity eine hilfreiche Dokumentationsmöglichkeit, da mithilfe des Velocity-Diagramms Belastungen, Störfaktoren und Ausreißer besser aufgezeigt werden können. Erforderliche Anpassungen können so besser begründet und veranschaulicht werden. Auch eine Bewertung des verfügbaren Projektpuffers ist dadurch besser möglich, Planungsoptionen können vorausschauender entwickelt werden.
• Verlässlichere Sprint-Planung: Hat sich ein Projektteam erst einmal eingespielt, so bleibt die Velocity im Verlauf des Projektes sehr konstant. Somit ermöglicht die Velocity belastbarere und längerfristige Prognosen zur Dauer des Projekts.

Welche Fehler sollte man im Umgang mit dem Velocity-Faktor vermeiden?

Richtig eingesetzt kann die Velocity sowohl innerhalb des Teams als auch in der Kommunikation mit Auftraggebern helfen, Risiken zu minimieren und Projektverläufe besser vorherzusehen. Falsch verwendet kann die Velocity allerdings auch gegenteilig wirken. Im Umgang mit der Velocity sollten Product Owner, Scrum Master und Teammitglieder, aber auch Auftraggeber deshalb nachfolgende Fehler vermeiden:

• Nicht kurzfristig interpretieren: Die Velocity von Entwicklungsteams muss sich erst aufbauen. Zudem kann sie durch einzelne Störfaktoren auch kurzfristige Schwankungen erleben. Die Velocity sollte deshalb weder zu schnell nach Projektbeginn noch zu kurzfristig im Prozessverlauf interpretiert werden. Nur bei mittel- und langfristiger Auswertung bietet die Velocity verlässliche und belastbare Resultate.
• Keinen Druck aufbauen: Die Versuchung ist groß, die Velocity eines Entwicklungsteams immer weiter pushen zu wollen. Dies funktioniert jedoch nicht, da die Ressourcen von Teams begrenzt sind. Vielmehr sollte die Velocity daher als Motivationsinstrument genutzt werden, um dem Team, aber auch allen Stakeholdern, positive Auswirkungen von Veränderungen aufzuzeigen. Zudem kann die Velocity helfen, ein positives Arbeitstempo zu erreichen, das vom Team während des gesamten Projekts durchgehalten werden kann. Die Konstanz des Arbeitstempos steht also im Mittelpunkt, nicht dessen Maximierung.
• Keine Rückschlüsse auf die Zufriedenheit ziehen: Auch wenn in der Regel nur harmonisierende Teams auch leistungsstarke Teams sind, so lässt umgekehrt eine hohe Velocity noch keine verlässliche Aussage über die tatsächliche Zufriedenheit der einzelnen Teammitglieder zu. Diese kann und sollte nur durch eine gute Teamkommunikation ermittelt werden.
• Keine Teams und Projekte vergleichen: Weil jedes Team eigene Prozesse durchlaufen muss und jedes Projekt eigene Herausforderungen bietet, eignet sich die Velocity nicht zum Vergleich von Teams und Projekten. Wer die Velocity dazu nutzt, die Leistung von Teams zu beurteilen, riskiert zudem, dass das jeweilige Team die erreichbaren Story Points extrem optimistisch einschätzt, um möglichst hohe Werte zu erzielen, wodurch eine realistische Abschätzung der Teamleistung unmöglich wird.
• Keine Leistungen Einzelner bewerten: Genau so wenig, wie sich die Velocity zum Vergleich von Projektteams eignet, sollte die Velocity zur Bewertung oder gar zum Vergleich einzelner Teammitglieder herangezogen werden. Ein solches Vorgehen würde nicht nur wichtige Prozesse innerhalb des Teams torpedieren, sondern dem Zusammenhalt und somit der Effektivität des gesamten Teams schaden.
• Nicht in Geld und Zeit umrechnen: Auch wenn es im Einzelfall sinnvoll sein kann, den konkreten Wertbeitrag einer Story zu messen, so sollte die Velocity dennoch nicht einfach in Zeit oder letztlich in Geld „übersetzt“ werden. Denn wenn eine gute und effiziente Teamleistung letztlich nur in Geld übersetzt wird, könnte dies den Bemühungen des Teams schaden, die Velocity aus eigenen Kräften zu optimieren. Zudem würden interne Teamdynamiken nicht ausreichend gewürdigt werden.