De magische kracht van de velocity

André Heijstek, directeur van Valueminds:

‘Wanneer ik een scrum training geef, krijg ik regelmatig vragen als: ‘Hoe gaan we om met bugs in agile? Krijgen bugs ook story points? Komen ze ook op de backlog?’. Wat helpt om deze vragen te beantwoorden, is het hebben van een goed beeld van Velocity.

De velocity is een maat voor de vaardigheid van een ontwikkelteam en geeft aan hoeveel story points per sprint kunnen worden gebouwd. Velocity is – mits goed toegepast- een krachtig instrument in agile projecten. Wanneer je je velocity weet, kan je goed voorspellen hoeveel user stories je in komende sprints kan gaan realiseren.

De voorwaarde hiervan is wel dat je de grootte van de user stories inschat in story points. Story points inschatten is eenvoudig. Je neemt in de eerste sprint de kleinste user story en die user story heeft de grootte van één story point.

Alle stories die hierna komen worden relatief ten opzichte van deze story geschat. Drie keer zo groot, vijf keer zo groot, enzovoorts. Je kan hiervoor planning poker gebruiken. In een later stadium kan je naast de ene story van 1 point ook andere stories aanwijzen als referentie-set: ‘Deze story is bij ons de referentie voor drie punten, die voor vijf.’ Je voorkomt dan de zogenaamde ‘story point inflatie’ en de waarde van de story points blijft hetzelfde.

De magische krachten van de velocity uiten zich nu op de volgende manier: Stel, je team is in een sprint niet zo succesvol en er worden bij het opleveren veel bugs gevonden. Dan kan je in de volgende sprint minder werk oppakken, omdat er naast de nieuwe stories ook bugs moeten worden opgelost. In dat geval is de velocity te hoog voor de vaardigheid van je team. Wanneer je team een lagere velocity heeft, krijgt het team in de volgende sprint automatisch meer tijd en rust om goed te ontwikkelen. Hierdoor zullen dan weer minder fouten worden gemaakt. De hogere kwaliteit van de software zal langzamerhand ook gaan leiden tot een hogere productiviteit waardoor op termijn de velocity weer kan stijgen.

Het is logisch dat dit alleen goed gaat, wanneer er aan bugs geen story points worden toegekend. Bij sommige opdrachten kom ik nog wel eens tegen dat er story points aan bugs worden toegekend, maar dit helpt het magische mechanisme meteen om zeep. Door de bugs zakt de velocity in nieuwe sprints en dit is de terechte straf die je krijgt voor het maken van die bugs. Als je jezelf gaat belonen voor het corrigeren van bugs, door daaraan story points toe te kennen, komt nooit het feedback mechanisme tot stand dat zorgt voor ‘first-time-right’ development.

Wanneer je schat in uren in plaats van in story points, werkt het mechanisme ook veel minder goed. Een schatting in uren is een minder stabiele factor dan het schatten in story points. Als je de vorige keer tien uur nodig had voor een story, en je er later achter kwam dat er veel bugs in zaten, dan zal de volgende keer een soortgelijke story meer dan tien uur gaan schatten. Het compensatie-mechanisme komt dan in de schatting zelf te zitten, en het mechanisme dat in de velocity zit wordt dan uitgeschakeld.

Heel wat input om mee aan de slag te gaan dus! Voor de volgende sprint heb ik een to do list opgesteld:

  1. De grootte van stories in story point schatten. Je begint met de kleinste story, vervolgens schat je grotere stories ten opzichte van de eerste. Zo bouw je gaandeweg een referentie-set op;
  2. Nu ben je klaar om de velocity van het team te schatten. Het is prima om de eerste keer story points even om te rekenen naar uren. Maar na deze eerste sprint is die omrekening niet meer nodig, want dan heb je de behaalde velocity als basis;
  3. Stel aan het einde van de sprint vast, wat de werkelijk behaalde velocity was. Gebruik deze waarde dan weer als basis voor de volgende sprint. Je kan daarna eventueel de kwaliteit van het sprint resultaat compenseren. Heb je veel bugs? Dan ga je voor een lagere velocity.’
0 antwoorden

Plaats een Reactie

Meepraten?
Draag gerust bij!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.