Blijf jij Story Points gebruiken?

Alhoewel het geen onderdeel uitmaakt van Scrum gebruiken de meeste Scrum teams story points. Dit concept vindt zijn oorsprong in XP (Extreme Programming). De bedenker van story points, Ron Jeffries, verontschuldigde zich in 2019 voor het uitvinden ervan en adviseert het niet meer te gebruiken. In deze blog worden enkele voor- en nadelen van het gebruik van story points benoemd. Tot slot worden er alternatieven aangedragen voor het gebruik van story points.

DE OORSPRONG VAN STORY POINTS

Het concept story points vindt zijn oorsprong in Extreme Programming  (XP) en werd  overgenomen door Agile practici. In XP is een user story een beschrijving van een initiële eis van de klant. Ron Jeffries, geestelijk vader van het story point concept, begrootte dergelijke user stories aanvankelijk in ‘ideale mandagen’. Dit is het aantal dagen dat het team nodig zou hebben om een user story af te krijgen zonder tussentijdse onderbrekingen. De schatting van ideale mandag werd uiteindelijk via een belastingfactor omgerekend naar de werkelijke implementatietijd. Bijvoorbeeld een user story geschat op drie ideale mandagen vermenigvuldigd met de belastingfactor van drie gaf een schatting van negen dagen. De stakeholders van het team waren echter in de war met een schatting van drie ideale dagen tegenover negen niet-ideale dagen, dus liet Ron’s team het communiceren in dagen los door ze simpelweg ‘Points’ of ‘Story Points’ te noemen.

DE VOORDELEN VAN STORY POINTS

Schatten in story points is snel. Teams die in dagen schatten hebben de neiging om hun discussie te gedetailleerd te voeren. Als je in dagen schat, speelt de angst voor commitment hier een rol. Bovendien gaan teams veelal in discussie over details, die nauwelijks invloed hebben op het inschatten van de omvang van het werk. Jeff Sutherland stelde vast dat schatten in story points de schattingstijd met 80% vermindert. Deze tijd kan een beter kunnen benutten voor meer waardevolle activiteiten.

Schatten in story points is relatief. Mike Cohn schreef in het boek Agile Estimating and Planning dat het niet uit maakt of onze schattingen juist, een beetje onjuist, of erg onjuist zijn, omdat de schatting van onze werkzaamheden relatief worden gemaakt ten opzichte van andere schattingen. Waar het om gaat is dat ze consistent zijn. Bovendien blijkt uit onderzoek dat mensen goed zijn in relatieve schattingen in vergelijking met absolute.

Het ondervangt het verschil in ervaringsniveau tussen teamleden. Een junior en een senior teamlid zullen werk in absolute zin verschillend inschatten, maar relatief hetzelfde. Een ervaren teamlid kan bijvoorbeeld twee dagen nodig hebben voor werk-item A en één dag voor werk-item B. Een junior teamlid bijvoorbeeld respectievelijk vier en twee dagen nodig. De absolute schattingen verschillen, de relatieve niet.

Het vermindert de angst voor een commitment. Het schatten met behulp van uren, creëer vaak de verwachting dat een schatting een commitment wordt om het werk in de geschatte tijd te leveren. Schatten in story points voorkomt dat je een exacte toezegging impliceert. Het is een abstractere maat van de te verwachten inspanning. Door een schatting van omvang in plaats van een schatting van de duur, kun je in de praktijk ondervinden hoeveel werk je in een gegeven tijdsinterval kunt uitvoeren. Hiermee kun je de totale verwachte doorlooptijd van een verzameling werk-items inschatten zonder de duur te schatten van de individuele werk-items.

Het elimineert de noodzaak voor frequente herschatting. Het inschatten van werk in een absolute maat in uren dwingt herziening daarvan af, zodra het team dat de werkzaamheden uitvoert effectiever en/of productiever leert samen te werken. Iets dat eerder in tijd als vijf dagen werk werd beschouwd, kan wellicht misschien nu wel in vier dagen worden uitgevoerd. Dit maakt dat alle eerdere gedane schattingen voor werk-items (die nog verricht moeten worden) herzien moeten worden. Door het werk relatief te schatten voorkom je die noodzaak. Zolang de relatieve verhouding tussen de werk-items ongewijzigd blijft, is er geen noodzaak om schattingen aan te passen. Stel dat de samenwerking in een team dermate verbetert is dat ze twee keer zo snel zijn, dan zullen ze twee keer zo veel story points per iteratie op kunnen leveren. Als de relatieve verhouding tussen nog op te leveren werk-items ongewijzigd blijft, hoef je de schattingen niet aan te passen. Het enige dat verandert is dat de doorlooptijd van het totaal aan resterend werk korter is. Het is dan ook van belang dat een team er voortdurend scherp op toe blijft zien of er aanleiding is om de relatieve omvang van één of enkele items uit de resterende werkvoorraad te herzien. Bijvoorbeeld omdat het team iets specifieks heeft geleerd, dat alleen van toepassing is op één of enkele items in de (resterende) werkvoorraad.

Story Points helpen om cross-functioneel gedrag te stimuleren. Eerder is gesteld dat teams goed zijn in het relatief schatten van werk. Een Agile team bestaat uit mensen van verschillende disciplines die samen een werk-item realiseren die van waarde is voor een klant of gebruiker. In de context van een software ontwikkelteam kan het bijvoorbeeld gaan om bijvoorbeeld programmeurs, analisten en testers. Zij ontwerpen, bouwen en testen een individueel stuk softwarefunctionaliteit dat inspeelt op de behoefte van een gebruiker. In Agile teams wordt de mindset benadrukt dat je niet strikt een bepaald specialisme uitvoert in een team, maar verantwoordelijk bent voor het geheel dat je als team oplevert. Nu kan de ene discipline zeer waarschijnlijk moeite hebben om het werk van een andere discipline in te schatten. Wat elke discipline wél kan is om de omvang van de inspanning nodig voor het realiseren van zo’n stuk functionaliteit relatief te schatten aan de omvang van een ander stuk functionaliteit. Dit maakt het niet alleen mogelijk om samen (relatief) te schatten, het stimuleert ook het cross-functioneel denken en werken.  Wat we als team samen leveren is wat telt, niet de individuele bijdrage.

Schatten in story points legt snel informatie bloot. Het is de conversatie tijdens het inschatten die het meest waardevol is om tot een gemeenschappelijk begrip van het werk te komen. De verschillende schattingen kunnen het gevolg zijn van bepaalde aannames. Door deze met elkaar te delen creëer je een beter begrip.

Schatten in story points benadrukt onzekerheid. Het Agile werken is bedoeld voor complexe domeinen waar meer onbekend is dan bekend. Toch is er veelal een behoefte aan voorspelling. Wat kunnen we in tijd leveren of wanneer kunnen we een bepaalde scope opleveren.  Door gebruik te maken van een Fibonacci-achtige reeks (1,2,3,5,8,13… etc) waarmee je de schatting van omvang uitdrukt, benadruk je dat we te maken hebben met onzekerheid. De keuze van een specifiek getal uit deze reeks weerspiegelt de mate van onzekerheid in de schatting. Hoe hoger de waarde hoe groter de onnauwkeurigheid. We kunnen weliswaar als mensen goed relatief schatten, maar we beperken ons bewust tot de waarden uit de Fibonacci-achtige reeks. We kunnen namelijk onmogelijk schatten dat een werk-item A 2,65 zo groot is als een werk-item B. Een Fibonacci-achtige reeks helpt ons dan wel (snel) richting te geven aan onze relatieve schattingen, maar beperkt ons tegelijkertijd. Voor de totale optelsom van de omvang van het werk (dat nodig is om een bepaald doel te bereiken) is gelukkig de ‘wet van de grote aantallen’ van kracht. Het statistisch concept dat aangeeft dat naarmate het aantal in een berekening meegenomen eenheden groeit, de invloed van een afzonderlijke eenheid steeds kleiner wordt (de invloed van uitschieters neemt dan af, de resultaten stabiliseren zich).

DE NADELEN VAN STORY POINTS

Teamleden vinden het lastig om het schatten in uren los te laten. Ze zijn gewend in hun hoofd een decompositie te maken van hun specifieke aandeel in het werk i.p.v. cross-functioneel te denken. En proberen op basis daarvan een schatting van de duur van de taken een schatting te maken in plaats van breder te denken en volledige werk-items relatief te vergelijken.

Teamleden besteden meer tijd dan nodig. Het besef van onnauwkeurigheid wordt vergeten. Teamleden kunnen oeverloos door blijven discussiëren in een poging consensus te bereiken over de inschatting. Is iets een vijf of een acht?

Niet leren van schattingen. Zo nu en dan zit een team er flink naast met een story point inschatting. Het is belangrijk om deze gevallen te bespreken en te proberen ervan te leren, om toekomstige schattingen beter te doen of individuele eerdere schattingen te herzien. We hebben eerder al gezien dat de wet van de grootte aantallen in ons voordeel is. Toch is het de vraag of je het kunt permitteren om niet te leren van je schattingen. Is dat nu net niet de aard van Agile werken? Inspecteren en aanpassen? Is het niet in het belang van een team en klant om op tijd te weten waar ze samen aan toe zijn?

Niet de moeite nemen om relatief te schatten. Zoals eerder gesteld is het van belang dat de relatieve schattingen zo consistent mogelijk zijn. Relatief schatten betekent dan ook letterlijk relatief schatten; elk nieuw werk-item schatten schatten ten opzichte andere reeds ingeschat werk-items. Vindt een team iets een omvang drie? Vergelijk het dan eens met ander soortgelijk werk met diezelfde omvang. Wellicht kom je dan tot andere inzichten dan oorspronkelijk gedacht. Door niet relatief te schatten, schat je eigenlijk op een onderbuikgevoel. De vraag is hoe consistent dat onderbuikgevoel over tijd is.

Het spreekt niet de taal van onze klant. Onze klanten en stakeholders vertellen dat iets een “twee” of een “drie” is, helpt niet bij het introduceren van nieuwe manieren van samenwerking. Hoe zou jij dat vinden? Geeft het je vertrouwen? Bovendien nemen de meeste teams te weinig tijd om de klant mee te nemen in dit concept. En laten we eerlijk zijn, meeste stakeholders zijn geïnteresseerd is wat ze kunnen krijgen en wanneer.

Story points zijn voor elk team verschillend. Het aantal story points dat een team kan leveren in een vaste periode noemen we de velocity van het team. Echter hoe een team de Fibonacci-achtige reeks (1,2,3,5,8,13… etc.) gebruikt verschilt van team tot team. Hierdoor zal zowel velocity als de optelsom van de totale inspanning van het werk in elk team kunnen verschillen. Het wil nog wel eens voorkomen dat iemand buiten het team de verkeerde conclusie trekt dat de velocity van het ene team hoger is dan het andere team.

Middelen van story point schattingen. Tijdens een schatting door een team kan het zijn dat de helft van het team een werkitem op drie story points schat en de andere helft op vijf story points. Het is gemakkelijk om de discussie op te lossen door gewoon vier story points als schatting te nemen. Hiermee creëert een vals gevoel van nauwkeurigheid. Het streven is niet om 100% accuraat te zijn. Het streven is nauwkeurig genoeg te zijn om vooruit te plannen. Bovendien vermijd het middelen een mogelijk waardevolle discussie die meer inzicht geeft in de omvang van het werk. Misschien was vijf story points een betere schatting.

WAT IS HET ALTERNATIEF?

Allereerst is er natuurlijk al sinds jaar en dag het #NoEstimates initiatief. Als je als team dermate voorspelbaar bent geworden dat het inschatten (van werk-items) geen toegevoegde waarde meer heeft, waarom zou je? Of wanneer niemand hoeft te weten wat wanneer zal worden gebouwd. En wanneer niemand van tevoren hoeft te weten waaraan het geld in een bepaald kwartaal of jaar zal worden besteed om de begroting rond te krijgen, is er geen reden om ramingen te maken.

Maar als je wél in een omgeving zit waar schattingen toegevoegde waarde hebben, zijn er in de loop der tijd zinvolle alternatieven bedacht op story points waaronder Blink Estimation / Wisdom of Crowds, Story counting, Bayesian probability en Monte Carlo Simulation. Laatstgenoemde is een interessant concept met als uitgangspunt ‘meten is weten’. De basis is het meten van de doorlooptijd van een werk-item, vanaf het moment dat je eraan begint tot het moment dat het is afgerond (cycle time). Deze meetgegevens worden gevisualiseerd in een Cycle Time Scatter plot. Hieruit kan de zogenaamde Service Level Expectation (SLE) vastgesteld worden. Een SLE voorspelt hoe lang een gegeven werk-item erover zou doen om van het begin tot het einde door de workflow van team te stromen. Een team gebruikt haar SLE om actuele problemen in de flow te ontdekken en om te inspecteren en aan te passen in de gevallen waarbij deze beneden verwachting zijn. De SLE zelf bestaat uit twee delen: een bereik van verstreken dagen en een waarschijnlijkheid die met die periode wordt geassocieerd. Bijvoorbeeld 85% van de werk-items zouden binnen 8 dagen of minder afgerond moeten zijn. Om een voorspelling te doen wat de te verwachten inspanning is voor een verzameling werk-items, worden de gemeten (historische) waarden voor de cycle time van werk-items gebruikt in een Monte Carlo Simulatie (MCS). Het uitgangspunt van een Monte Carlo simulatie is vrij eenvoudig; in het verleden behaalde resultaten voorspellen toekomstige resultaten. Via duizenden zo niet miljoenen simulaties op basis van eerdere geregistreerde cycle times, wordt ons vermogen om de toekomst te voorspellen verbetert. In een andere blog zal ik hier uitgebreider op ingaan. Voor de nerds onder ons, check alvast deze video over Monte Carlo Simulation.

REFERENTIE

Cohn, M. 2006 “Agile estimation and planning.” Prentice Hall Professional Technical.

Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!