Folge 091 Velocity

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.


Denn 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

Die 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 / 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.
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

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:


StoryPoints

StoryPoints wegstreichen

Daily

Product Ownerin

Agilität

Stakeholdern

SlackTime

Commitment

Team

Facilitator



Connecte dich gerne hier mit uns:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post Folge 091 Velocity appeared first on Znipcast - für gute
Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.