Velocity

Heute wieder ein Henry Schneider Thema: Velocity. Also Geschwindigkeit und irgendwie auch nicht. Jedenfalls geht es wieder ums Messen und Überprüfen. Eine Freude für Projektleiter.

Motorrad im Dunkeln, futuristisch auf einer Straße, mit blau leuchtendem Hinterrad - Velocity - Geschwindigkeit ist nicht gleich GeschwindigkeitDenn heute lernen wir wieder eine Messgröße im Agilen kennen, die uns dabei unterstützt das Projekt zu steuern, Voraussagen zu treffen und vor allem auf das Team zu achten.

Wenn Du einen größeren Vortrag zu diesem Thema in Deiner Firma möchtest, dann schreib uns an hello@znip.academy. Wir lieben nämlich Velocity und haben schon einige Jahre Erkenntnisse mit diversen Teams dazu gesammelt.

Diese Folge auf YouTube: https://youtu.be/fxHYrEe2MvI

Übersetzungsprobleme

Im Englischen gibt es zwei Wörter für Geschwindigkeit. Das eine ist Speed und das andere ist Velocity. Bei der Velocity geht es um die Veränderung des Ortes näher auf das Ziel hin. Bei Speed geht es nur um die Geschwindigkeit mit der ich mich bewege. Dieses kann auch in die falsche Richtung sein. Ein Marathonläufer, welcher Startpunkt und Zielpunkt an derselben Linie hat, der hat sicherlich eine hohe Geschwindigkeit (Speed), aber 0 Velocity, da dieser sich im Ergebnis örtlich nicht verändert hat. Velocity ist also zielgerichtete Geschwindigkeit.

Es geht nicht ums schneller werden

Häufig wird Henry zu Projekten gerufen, die jetzt Agil arbeiten sollen, damit es schneller geht. Das ist nicht die Idee dahinter. Initial wird das Projekt sogar meist langsamer. Wir beschäftigen uns daher mehr mit Outcome, statt Output. Ein Nebeneffekt davon ist häufig, dass der Kunde schneller und häufiger Mehrwert geliefert bekommt. Das Projekt perse wird dadurch nicht immer schneller, sondern eher die unnötigen Dinge weggelassen. Bei der Velocity geht es also auch wieder verstärkt um den Kundennutzen.

StoryPoints als Grundlage

Als Grundlage für die Velocity nehmen wir nun die StoryPoints, die wir bereits eingeführt haben, her. Wenn Du Fan von NoEstimation bist, dann kannst Du auch die Anzahl Stories / Anforderungen hernehmen. Diese StoryPoints beschreiben die Komplexität und wenn sie erledigt sind, wie viel Komplexität das Team bewältigt hat. Dies messen wir.

Die Berechnung

Velocity = CustomerValue / TimeDie eigentliche Berechnung ist: Velocity = Customer Value / Sprints

Allerdings habe ich noch kein Team erlebt, welches seinen Customer Value kennt. Falls Du eins hast, cool! Dann nimm natürlich Costumer Value. Ansonsten kannst Du Dich des Kniffes der StoryPoints bedienen, welche ja die Komplexität aufzeigen.

Also: Velocity = StoryPoints / SprintsVelocitiy = StoryPoints / Sprints

Henry selbst nimmt Personentage statt Sprints um auch Urlaubs- und sonstige Fehlzeiten (auch durch Feiertage) herauszurechnen. Messzeitpunkt ist dabei immer das Daily.

Welche StoryPoints werden gezählt? Dabei noch einmal der Hinweis zur Folge StoryPoints wegstreichen. Also wirklich nur von erledigten Aufgaben.

Es dauert etwa 6 Sprints bis ich nun verlässliche Aussagen zur Velocity treffen kann.Velocity = StoryPoints / PeopleaDays

Extrapolation

Mit irgendeiner dieser Formeln kommst Du nun bei einer Zahl raus, wo Du in etwa abschätzen kannst, was das Team so pro Sprint wegarbeitet.

Habe ich jetzt genug Velocity gemessen kann ich diese in die Zukunft extrapolieren und so dem Team und vor allem der ProductOwnerin dabei helfen sich im Planning eine faire Menge an Aufgaben vorzunehmen. Auch weiß so die Product Ownerin so in etwa, was das Team im Schnitt schafft und kann dies in die Kommunikation mit Stakeholdern einbeziehen.

Möchte sich Dein Team nun zu deutlich mehr StoryPoints für den nächsten Sprint Commiten, als es sonst im Durchschnitt abarbeitet, dann bietet die Velocity eine gute Diskussionsgrundlage.

Beobachtungen

Wenn wir nun die Velocity auf ein Chart auftragen (unten die Sprints, auf der Y-Achse die StoryPoints), können wir beobachten, was bestimmte Experimente in der Vergangenheit für Auswirkungen hatten. Beispielsweise, dass die Kommunikationskomplexität sinkt, wenn Teammitglieder im Urlaub sind. Wird dann vielleicht sogar mehr geschafft?

Wie lange dauert die Einarbeitung? Welche Auswirkung hat es Projekte parallel zu betreiben? Wie verändert SlackTime die Velocity? Kann ich aktuell Hospitationen zulassen?

Das Chart

Velocity Chart

Wenn Du die Velocity nun über eine längere Zeit misst und auf einem Chart abträgst, dann bewegt sich diese wie ein Börsenkurs hin und her. In der Literatur findet sich häufig, dass diese gleichmäßig steigen muss und danach beauftragt werden kann. Das stimmt nicht mit unserer Realität überein. Die Velocity schwankt und daran kannst Du ablesen wie der Zustand des Teams ist und ob es Experimente wagen kann.

Es ist häufig sogar gut, wenn die Velocity über die Jahre leichtfällt. Beispielsweise durch StoryPoint Deflation, weil die Definition of Done erweitert wird, oder das Team einfach mehr innerhalb der Aufgaben macht. Testautomatisierung beispielsweise.

Nicht vergleichen!

Velocity Charts lassen sich schon allein wegen der Schätzung nicht über Teamgrenzen hinaus miteinander vergleichen. Auch bringt es keinen Mehrwert. Denn was meist passiert, ist dass dem Team dann gesagt wird, es müsse schneller arbeiten, da die anderen Teams mehr StoryPoints schaffen. Da wir bekommen, was wir messen, werden dann einfach die StoryPoints höher geschätzt und wir haben nix erreicht, außer das Gefühl von Kontrolle… Lass es also gleich. 😉

Technische Schulen

Ein Thema, was Henry noch am Herzen liegt: Technische Schulden. Diese sieht man auch sehr gut auf dem Velocity Chart. Vor allem wenn die Velocity über einen längeren Zeitraum plötzlich sinkt. Eine mögliche Ursache könnten dann genau diese technischen Schulden sein, die dann schleunigst aufgeräumt gehören.

Deflation

Wie bereits erwähnt kommt es häufig vor, dass Teams mit der Zeit einfach mehr Komplexität mit dem gleichen AUfwand bewältigen und dies nicht näher markieren. Beispielsweise, Stories, die früher mit 8 StoryPoints bewertet wurden, werden heute mit 3 bewertet. Einfach, weil es jetzt easy oder Usus fürs Team geworden ist. Das kann man rausrechnen oder entsprechend anpassen und neu bewerten oder es lassen. Häufig lohnt die Korrektur nicht. Du als Facilitator darfst dies aber wissen und im Auge behalten, wenn Du auf das Velocity Chart blickst.

Dies hängt unter anderem auch von der aktuellen Definition of Done ab.

 

Get shit done,

Janina & Henry


Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.


Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉


In der Podcastfolge erwähnte Folgen zur Vertiefung:


Connecte dich gerne hier mit uns:

LinkedIn

Instagram

YouTube

Facebook

Webseite

Facebook-Gruppe

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert