De term ‘velocity’ wordt in Scrum gebruikt om aan te geven hoeveel werk een development team per sprint kan doen. Doordat velocity vaak in een getal uitgedrukt wordt, is het makkelijk vergelijken. Het gevolg hiervan is dat velocity vaak in de praktijk niet ingezet wordt zoals het bedoeld is.
De aanloop naar velocity
Ron Jeffries wordt in het algemeen aangewezen als de persoon die het concept van story points bedacht heeft. Mike Kohn heeft het in zijn boek Agile Estimating and Planning ook over story points.
Om werk in te kunnen schatten gaan beiden ervan uit, dat mensen in het algemeen niet goed zijn in het inschatten van tijd. Daarom bedachten ze story points, waarbij elk cijfer een globale inschatting is van hoeveel werk iets is. Het is dus niet de bedoeling om te schatten in het aantal dagen of uren, maar meer in een globale orde van grootte. Een voorbeeld is dat een koe en een paard van ongeveer dezelfde grootte zijn, maar een olifant duidelijk groter is. De koe en het paard krijgen hetzelfde puntenaantal en de olifant zal een hoger puntenaantal krijgen.
Daarna zijn er mensen geweest die story points bij elkaar op gingen tellen. Zo is het begrip velocity ontstaan: de snelheid waarmee je user stories af kan maken.
The good
Binnen een team kunnen de teamleden user stories inschatten en daarmee bepalen of ze op dezelfde lijn zitten in hun verwachting hoeveel inzet het kost om de user story te verwerken in de applicatie.
Story points zijn primair bedoeld om discussie uit te lokken, omdat meerdere teamleden een verschillend aantal punten geven voor een user story. Doordat deze cijfers goed te vergelijken zijn, is het direct duidelijk als je niet hetzelfde beeld hebt. Het aantal punten dat je denkt dat de user story kost is immers verschillend.
Als je de punten van de stories die je op de sprint backlog zet bij elkaar optelt, kom je tot een aantal punten waarvan je denkt te kunnen verwerken tot werkende software in deze sprint. Als je dit aantal punten bijhoudt per sprint zul je een trend zien die aangeeft hoeveel punten het team ongeveer kan verwerken per sprint. Hierdoor wordt het in de sprint steeds makkelijker en voorspelbaarder plannen voor het team. Daarnaast wordt het voor de Product Owner makkelijker om in te schatten wanneer een bepaalde functionaliteit in zijn totaal af kan zijn of dat het team eraan kan beginnen.
The bad
In oudere versies van Scrum was de sprint planning een commitment. Je tekende bijna af, dat het wel afkomt. Zelfs organisaties die in die tijd nog geen Scrum deden, gaven wel signalen af velocity op die manier te gebruiken. Typische vragen zijn dan ook: “Waarom is de sprint niet in z’n volledigheid opgeleverd?”
Ergens is het idee opgevat, dat Velocity hoger moet. Wellicht dat dit door de term komt (snelheid) of omdat het makkelijk te vergelijken is met eerdere sprints. Daarnaast denk ik dat het boek van Jeff Sutherland – Twice the work in half the time, organisaties het idee geeft dat teams 4 keer zoveel op kunnen leveren. Dit boek gaat over het leveren van meer waarde en over door focus sneller tot resultaten van die waarde te komen.
Velocity is echter de snelheid die het team aankan. Het is afgeleid van de punten die het team zelf ingeschat heeft en zelf kan aanpassen.
Velocity is makkelijk te meten, dus moet we dat ook meten. In een omgeving waarin men de teams nog niet zelf organiserend durft te laten zijn, willen managers graag alles meten wat ze kunnen meten. Zonder dat de uitkomst direct resulteert in verbeteringen, maar alleen om het gevoel van controle te houden. Het wordt zelfs bij de teams opgelegd, dat alle PBI’s (user stories, maar soms ook bugs) punten moeten hebben.
The ugly
Managers gebruiken het als KPI: 10% meer velocity dan vorig jaar.
Hier zitten wat issues aan:
- Meer user stories opleveren betekent niet meer waarde.
- Als teams dit proberen door sneller te werken zal de kwaliteit omlaag gaan.
- Teams zullen geen experimenten doen, want dat kost hun velocity. Er zal dus ook niet iets geprobeerd worden om inderdaad sneller te kunnen, omdat iets nieuws leren op korte termijn ten koste gaat van de velocity.
- Er is geen ruimte om te investeren in het structureel verhogen van de kwaliteit. Als je automatisch testen wil introduceren voor een team, is dat niet even een knopje omzetten. Dit kost tijd en inzet. De velocity gaat in het begin omlaag, terwijl dat niet per se op de lange termijn terugverdiend wordt.
- Alles wat door het team gedaan wordt zal punten krijgen, want elk uur dat we anders besteden gaat ten koste van de velocity. Dit zal zelfs averechts gaan werken, want het meetinstrument “velocity” is nu waardeloos geworden, omdat het team nu tijdsbesteding gaat meten. Teams maken PBI’s aan voor zaken als refinement en afdelingsoverleg om maar aan hun velocity target te kunnen komen
Teams worden met elkaar vergeleken in velocity.
Elke team bepaalt op welke schaal de punten gegeven wordt. Het kan best gebeuren dat tussen twee teams het ene 120 punten oplevert en de ander ‘maar’ 30, terwijl ze net zoveel waarde voor de klant opleveren. Daardoor is het logischerwijs niet mogelijk om de velocity van teams met elkaar te vergelijken. Daarnaast creëert het vergelijken van velocity een onderlinge competitie, die samenwerking van teams tegenwerkt, doordat het ene team een hogere velocity wil hebben dan een ander.
Kostenpost
Velocity is een kostenpost: het is de benodigde effort om waarde te leveren. Waarde is de belangrijkste graadmeter, maar dat wordt vaak vergeten en is moeilijker te meten.
Hoe wordt velocity in jouw organisatie gebruikt?
Heb je vragen, opmerkingen of hulp nodig bij het juist gebruiken van velocity? Neem dan gerust contact met mij op via onderstaande link.
Alex Roos, DevOps Consultant/Agile coach
Lees ook:
– Hierdoor wordt het in de sprint steeds makkelijker en voorspelbaarder plannen
– Managers gebruiken het als KPI: 10% meer velocity dan vorig jaar
– Story points zijn bedoeld om discussie uit te lokken
