De onzin van Story Points in relatie tot Velocity

Het bepalen van een Velocity met behulp van Story Points is fundamenteel fout!

In de wereld van Scrum slaat het gebruik van Story Points behoorlijk aan.

Story Points zijn een manier om om te kunnen gaan met onzekerheid in een project. Op die manier heb je iets meetbaars, maar hoef je tegelijk geen uitspraken te doen over de tijd dat het kost om iets te implementeren.

Nu is er op zich niet veel in te brengen tegen het gebruik van Story Points, zolang je ze uitsluitend gebruikt om User Stories onderling te vergelijken. Het kan een goed hulpmiddel zijn bij het aanbrengen van prioriteiten. Ook kan het duidelijk maken dat een User Story te groot is en opgedeeld moet worden.

Waar het echter fundamenteel fout gaat is, wanneer Story Points opgeteld gaan worden om hiermee een Velocity te meten.

Een Story Point is een relatieve maat voor diverse zaken, zoals complexiteit, benodigde inspanning en onzekerheid. Er worden dus gegevens uit meerdere dimensies platgeslagen in een getal. Dit getal heeft alleen betekenis in relatie tot Story Points in andere User Stories. Story Points zijn verder absoluut niet bedoeld om hier een eenheid van tijd mee aan te geven.

Na afloop van een Sprint worden deze relatieve getallen bij elkaar OPGETELD. Van deze optelling wordt dan vervolgens gezegd dat dit de ontwikkelsnelheid is (Velocity). In een volgende sprint zouden dan evenveel story points gerealiseerd kunnen worden.

Wiskundig gezien slaat dit nergens op. Er is geen enkele reden om te veronderstellen dat een aantal Story Points met een bepaalde som een vergelijkbare hoeveelheid werk oplevert als een andere combinatie van Story Points met dezelfde som.

Uiteindelijk blijkt dat Story Points toch als maat voor werktijd gehanteerd worden door de meeste klanten/opdrachtgevers, terwijl dit expliciet niet de bedoeling is.

Ga maar na: als in een Sprint van twee weken met vier man (320 uur) 160 Story Points ‘gerealiseerd’ worden en dit ook maatgevend is voor een volgende Sprint van twee weken, dan kun je de logische conclusie trekken dat een manuur binnen dat team gelijk staat aan 0,5 Story Points.

De voorstanders van deze methode zullen direct aangeven dat dit niet de bedoeling is. Maar de vraag is wat dan wél de bedoeling is? Hoe je het wendt of keert: de Velocity wordt gehanteerd als maatgevend voor wat er in een Sprint (van twee of drie weken) gerealiseerd kan worden. 

Mijn aanbeveling zou zijn om toch maar weer in uren te gaan schatten. De PERT-methodiek is daarbij een statistisch meer verantwoorde manier om toch met onzekerheid om te kunnen gaan. En ook dan geldt dat een normale optelling van urenschattingen per taak of User Story niet mogelijk is.

Zie ook: Story Points and Velocity: Recipe for Disaster