“Hoe gaan we om met bugs in Agile? Krijgen bugs ook story points? Komen ze ook op de backlog?” Deze vragen krijg ik nogal eens als ik een Scrum training geef. Die vragen zijn gemakkelijk te beantwoorden als je een goed beeld hebt van Velocity.
Velocity is – mits goed toegepast – een bijzonder krachtig instrument in Agile projecten. De velocity is een maat voor de vaardigheid (capability) van een ontwikkelteam en geeft aan hoeveel story points per sprint kunnen worden gebouwd. Als je eenmaal je velocity weet, kan je goed voorspellen hoeveel user stories je in komende sprints kunt gaan realiseren.
Dat stelt wel de voorwaarde dat je de grootte van user stories inschat in story points. Story points schatten is eenvoudig. In de eerste sprint neem je de kleinste user story en stelt dat die user story een grootte heeft van 1 story point. Alle andere stories worden relatief ten opzichte van deze story geschat. Twee keer zo groot, vijf keer zo groot, enzovoorts. Planning poker is een prima methode om dit te doen met een groep. Later kan je, naast de ene story van 1 point andere stories aanwijzen als referentie-set. “Deze story is bij ons de referentie voor 5 punten, die voor 8”. Op die manier voorkom je de zogenaamde ‘story point inflatie’ en houd je de waarde van een story point stabiel.
De magische krachten van velocity uiten zich nu op de volgende manier. Als een team in een sprint niet erg succesvol was, en er bij het opleveren veel bugs gevonden werden, dan kan in een volgende sprint minder werk worden opgepakt. Er moet immers tijd vrijgemaakt worden om naast nieuwe stories te bouwen ook de bugs op te lossen. De gekozen velocity was blijkbaar te hoog, hoger dan de vaardigheid van het team. Met een lagere velocity krijgt het team in de volgende sprint automatisch meer tijd en rust om goed te ontwikkelen. Daardoor zullen er 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.
Dit gaat natuurlijk alleen goed wanneer aan bugs géén story points worden toegekend. Ik kom dat soms nog wel eens tegen, maar daarmee help je het magische mechanisme meteen om zeep. Het feit dat, door bugs, de velocity zakt in nieuwe sprints 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.
Het mechanisme werkt ook veel minder goed als je schat in uren in plaats van in story points. Een story point is een stabiele valuta, als je tenminste de goud-standaard van een referentie-set van stories goed bijhoudt. Een schatting in uren, of ideale uren, is veel minder stabiel. Als je de vorige keer 10 uur nodig had voor een story, en er later achter kwam dat er nogal wat bugs in zaten, dan zal je de volgende keer voor een soortgelijke story 12 of 13 uur gaan schatten. Het compensatie-mechanisme komt dan in de schatting zelf te zitten. Het mechanisme dat in de velocity zit wordt dan uitgeschakeld.
Dus: aan de slag ermee. Takenlijstje voor de volgende sprint:
- Schat de grootte van stories in story points. Begin met de kleinste story, schat grotere stories ten opzichte van die eerste. Bouw gaandeweg een referentie-set op;
- Schat de Velocity van het team. Dat kan de eerste keer prima door story points even om te rekenen naar uren. Na deze eerste sprint is die omrekening niet meer nodig, je hebt dan de behaalde velocity als basis;
- Stel aan het einde van de sprint vast wat de werkelijk behaalde velocity was, en gebruik die waarde als basis voor de volgende sprint. Compenseer eventueel voor de kwaliteit van het sprint resultaat, kies bij veel bugs een wat lagere velocity.
Overigens kan je hier kaarten voor Planning Poker bestellen.
André Heijstek, Improvement focus
