Als ich 2015 das erste Mal von Velocity in der Softwareentwicklung gehört habe, war ich begeistert.
Am eigenen Leib hatte ich bereits erfahren, wie unvorhersehbar die Entwicklung von Software sein kann. Stundengenaue Vorhersagen, wie lange die Umsetzung einer User Story dauern wird, kann deshalb niemand geben. Davon wegzukommen, indem die Arbeit relativ geschätzt und die Größe als Anzahl von Story Points festgehalten wird, klang genial. Die Anzahl der Story Points, die innerhalb eines Sprints erledigt wurden, als Velocity zu bezeichnen und zu nutzen, um damit Prognosen für die zukünftige Umsetzungsgeschwindigkeit zu treffen, fand ich genauso vielversprechend.
Heute denke ich anders.
Nachdem ich über die Jahre mit vielen Teams zusammengearbeitet habe, würde ich Velocity als Friendly Fire in der Produktentwicklung beschreiben. Damit stehe ich nicht allein da. Ron Jeffries, der Erfinder der Story Points, entschuldigt sich mittlerweile öffentlich für seine Idee. Wenn du mir nicht glaubst, findest du im Folgenden 5 + X Wege, wie du Velocity auch als Waffe gegen Scrum Teams einsetzen kannst.
Weg #1: Verwende Velocity, um Teams zu vergleichen
Der FC Bayern München erzielt im Schnitt 3 Tore pro Spiel. Der THW Kiel erzielt im Schnitt 29 Tore pro Spiel.
Welches Team ist besser?
Dieser Vergleich ergibt keinen Sinn. Einmal handelt es sich um Tore im Fußball und das andere Mal um Tore im Handball. Gleiches gilt auch für Scrum Teams. Unterschiedliche Teams arbeiten an unterschiedlichen Produkten. Teams bestehen aus unterschiedlichen Menschen. Obgleich Produktteams alle Software entwickeln, ist ein Vergleich ihrer Velocity wertlos.
Meiner Erfahrung nach hat es sich bewährt, Teams anhand ihrer Velocity zu vergleichen, wenn der Konkurrenzkampf unter ihnen geschürt werden soll oder der Wille zur Zusammenarbeit mit anderen Teams gebrochen werden soll.
Weg #2: Verwende Velocity als Maß für die Effektivität des Teams
Velocity ist ein Kapazitätsmaß.
Es ist kein Maß für Effektivität. Basierend auf der Velocity können keine Rückschlüsse gezogen werden, ob das Team „die richtigen Dinge tut“. Velocity beschreibt ausschließlich die Kapazität eines Teams. Ein anderes bekanntes Maß für Kapazität sind Arbeitsstunden. Weder Story Points noch aufgebrachte Arbeitsstunden lassen sinnvolle Rückschlüsse zu, ob ein Team mit dem, was es tut, ein angestrebtes Ziel bestmöglich erreicht.
Möchte man allerdings sicherstellen, dass das Team stets voll ausgelastet ist, dann ist die Velocity als Maß für die Teameffektivität ein erfolgversprechender Weg.
Weg #3: Gib die Velocity vor, welche das Team erreichen muss
Erst alle Anforderungen an ein zukünftiges Produkt zu sammeln, den Gesamtaufwand dieses Projekts zu schätzen und dann die benötigte Velocity zu errechnen, damit die Deadline erreicht wird, ist die beste Art, die ich kenne, um Teams jeglicher Kreativität zu berauben.
Die schlechte Nachricht: Es funktioniert nicht immer. Wurde der Gesamtaufwand fälschlicherweise zu hoch geschätzt, kann es aus meiner Erfahrung dazu führen, dass das Team seine Kreativität beim Kickerspielen entfaltet.
Velocity kann nicht vorgegeben werden, da sie ein Resultat ist. Setzt man sich über diese Tatsache hinweg, dann stellt dies einen bewährten Ansatz dar, Scrum wieder in einen wasserfallartigen Prozess zu verwandeln.
Weg #4: Weise das Team darauf hin, dass die Velocity steigen muss
Nachdem das Team endlich liefert, was vorab geschätzt wurde, ist klar, was kommt:
Manager wollen mehr davon, denn mehr ist immer besser.
Wird steigende Velocity mit Fortschritt verwechselt, gibt es zwei mögliche Szenarien. Das bessere zuerst: Das Team ist so mutig und schätzt in Zukunft Arbeit im Backlog einfach großzügiger. Das schlechtere: Das Team liefert mehr, verzichtet dafür allerdings auf Tests und eine Refaktorisierung der Codebasis.
Ein fast todsicherer Weg, die Qualität des Produkts zu ruinieren, besteht also darin, von Teams immer mehr Velocity zu fordern.
Weg #5: Treffe Vorhersagen basierend auf der durchschnittlichen Velocity
Nehmen wir für einen kurzen Augenblick an, du bist 1,70 m groß und kannst nicht schwimmen. Würdest du einen reißenden Fluss durchqueren, wenn ich dir versichere, dass er im Durchschnitt nur 1,40 m tief ist?
Wenn du nicht lebensmüde bist, wohl eher nicht.
Das Problem mit Durchschnitten ist: Es gibt Ausreißer. Die tiefste Stelle im Fluss kann durchaus 2,5 m betragen. So verhält es sich auch mit Prognosen, die auf dem Durchschnitt basieren. Angenommen, das Team hat in den letzten drei Sprints 10, 6 und 2 Story Points geliefert, würdest du deine Hand dafür ins Feuer legen, dass sie im nächsten Sprint 6 Punkte liefern?
Wenn man den Stakeholdern vorgaukeln möchte, dass sich in der Zukunft nichts ändern wird, auch wenn man bereits einen klaren Abwärtstrend beobachten kann, dann ist die durchschnittliche Velocity eine vielversprechende Möglichkeit, um diese Illusion aufrechtzuerhalten.
Weg #X: Welchen Weg habe ich vergessen?
Schreibe ihn in die Kommentare.
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für Dich. Wie man Velocity richtig verwendet, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.