SCRUM: uren vsStory Points

Als developer nooit meer afgerekend worden op een verkeerde inschatting

Ben je developer en bekend met SCRUM? Wel eens een User Story gehad waarbij je veel meer uur hebt besteed dan vooraf ingeschat? Tip: gebruik Story Points, hieronder lees je hoe wij hiermee bezig zijn.

Bij Eleven hebben we binnen onze SCRUM projecten de discussie gehad over hoe om te gaan met User Story Points en inschattingen. We merken dat er veelal teruggegrepen wordt naar inschattingen op uren, waarmee het nut van Story Points vaak ter discussie staat. De velocity per uur van voorgaande sprints bepaalde dan automatisch hoeveel storypoints een ticket zou moeten krijgen, maar dan bleef je toch weer werken met uren.

Het nadeel van inschatting op uren is dat je voorafgaand aan een Sprint dat niet exact weet vanwege de onzekerheden en risico’s die kunnen optreden of simpelweg door voortschrijdend inzicht.

Bij het inschatten van functionaliteiten zijn er altijd onzekerheden en risico’s die exacte inschattingen doorgaans niet mogelijk maken. Hierdoor krijg je vaker discussie over deze onzekerheden en risico’s tijdens een refinement, je wilt namelijk als developer voorkomen dat je een verkeerde inschatting maakt. Maar als projectteam heb je wel iets nodig om te weten hoeveel werk in een sprint past.

Tip: gebruik Story Points helemaal los van uren.

Story Points geven een grove indicatie van de hoeveelheid inspanning die nodig is om deze te realiseren. Complexiteit, onzekerheden (ook wel open eindes) en risico’s zijn factoren die invloed hebben op de bepaling van deze inspanning. Elk individueel factor is in ieder geval niet genoeg om die inspanning te bepalen. Door de fibonacci reeks te hanteren voor de Story Points, wat gebruikelijk is bij Scrum Poker, wordt je gedwongen om inschattingen niet (te) exact te maken. Een inschatting is ook altijd een indicatie ten opzichte van andere tickets in hetzelfde project.

Voor het maken van een inschatting heb je daarom per definitie goede referentie Stories nodig uit een van de eerste sprints, voor elk soort punten aantal. Je gebruikt altijd dezelfde referentie stories en deze pas je alleen aan als het team (structureel) op een project verandert, of als het team beter/efficiënter (of slechter) is geworden in de inschattingen. Deze referentie tickets zul je per project/team moeten documenteren en gebruiken met Scrum Poker tijdens de refinement sessies.

Alleen gedurende de retro grijp je ter evaluatie nog terug naar de urenregistratie. Als blijkt dat er na een sprint tickets zijn die uitschieten qua tijdsbesteding t.o.v. hun Story Points, dan is dat input om te bespreken tijdens de retro van die sprint. Het primaire doel van uitschieters te bespreken is om ervan te leren. Hierdoor worden inschattingen van het team beter, leren we van voortschrijdend inzicht en kunnen we als team nog beter bijdragen aan het succes van onze klanten.