Het blijft me verwonderen hoe het inschatten en toepassen van story points voor elk team weer een worsteling is. Blijkbaar hecht men er een grote waarde aan in verband met “de planning”, terwijl er in praktijk maar weinig empirisch bewijs is dat die idealen ooit waargemaakt worden.

Om beter te begrijpen waar we het over hebben, is deze blog post van Tim Ottinger een geweldige bron van inspiratie. Hierin wordt niet alleen de originele reden voor story points uitgelegd, maar ook met een analogie naar dobbelstenen uitgelegd hoe je deze getallen wél zou moeten interpreteren.

Samenvattend zijn story points dus een indicatie van “muchness”. Iedereen die ooit iets over statistiek heeft geleerd, zal hierbij bedenken dat bij kleine steekproeven het een heel slechte voorspeller vormt voor de hoeveelheid werk. Het kan wel gebruikt worden om verhoudingen uit te drukken, maar zeker niet als een middel om doorlooptijd in te schatten. Daarvoor is het ontwikkelen van software een te creatieve bezigheid met te veel verrassingen.

Mijn suggestie is daarom om story points hooguit te gebruiken als indicatie van “muchness”, zodat er beslissingen op genomen kunnen worden of bijvoorbeeld de waarde van de feature de investering wel waard is. Daarnaast is het een prachtig criterium om te beslissen of een story wel klein genoeg is om door het team opgepakt te worden.

Een praktische keuze is om de fibonacci reeks van waarden te gebruiken, en binnen het team met expliciete voorbeelden een eenvoudige richtlijn voor de laagste getallen uit de reeks op te stellen. Mensen zijn creatief genoeg om die verder te extrapoleren, en het geeft een eenvoudige referentie hoeveel “muchness” voor het team realistisch is om als story op te pakken.

En als je er met het team helemaal niet uit komt, dan zijn ook story points geen voorwaarde om Agile te kunnen werken. Eigenlijk is er niet meer nodig dan de keuze of iets “klein genoeg” is om door het team opgepakt te worden.