Story point liniaal

Story point lineaal Andre Heijstek André Heijstek, directeur van Valueminds:

‘Een van de taken in de refinement is het inschatten van user stories. Dat schatten hoort echt bij de refinement. Sommigen beginnen hier pas mee in de planning, maar wat mij betreft is dat te laat. Dit is, omdat wanneer stories al zijn ingeschat, het makkelijker is voor de product owner om gemakkelijk de juste hoeveelheid stories voor een sprint aan te bieden in de planning.

We schatten de stories natuurlijk met planning poker. Ik zal niet herhalen wat daar al allemaal over is geschreven. Om goed te kunnen pokeren heb je een baseline nodig. Als je weet wat een ‘1’ is, dan kan je alle stories daarmee vergelijken en inschatten. Deze is twee keer zo groot, die vijf keer, etc.

Ik vind zelf een baseline met alleen de ‘1’ te mager. Daarom maak ik voor mijn team graag een story point liniaal waarin ik voor diverse getallen uit de pokerset (1, 2, 3, 5, 8, 13, …) een paar voorbeeldstories in opneem.

Schatten wordt nu een stuk gemakkelijker. Je houdt de story naast de liniaal en je vergelijkt: is hij groter dan de stories die we eerder als drie hebben ingeschat, maar kleiner dan de achten? Dan moet dit wel een vijf zijn.

Mijn ervaring is dat als teams hier twee meetings mee hebben gewerkt dat het dan gesneden koek is. Als scrum master zorg ik er altijd voor dat ik een paar kopieen van de liniaal bij me heb als we de backlog refinement doen. Wanneer de discussie over de story is afgerond stel ik de vraag: “Kunnen we al pokeren?”. Als dit het geval is, pakt iedereen zijn kaarten, vergelijkt nog even met de liniaal, legt de kaarten op tafel en het pokeren kan beginnen.’

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.’