Scrum story points zijn zinvol maar waardeloos.

This post in English.
Hoe vaak hebben we er als Scrum-beoefenaren niet op gehamerd dat je story points niet mag zien als een ureninschatting? Nou, zo vaak dat ik mij begin af te vragen of er misschien toch iets schort aan die obsessie met punten. Mocht je zoals ik de aanvechting voelen om met het Scrum-bijbeltje te wapperen en eens haarfijn uit te leggen hoe het ook alweer zit met punten: ook in de editie 2020 rept de Scrum guide nergens over velocity of story points en hoe we die horen te interpreteren. Met geen woord. Ook verbaasd? The developers who are doing the work are responsible for the sizing, komt nog het dichtst in de buurt. Daarentegen zijn er wel 18 variaties op aanpassingsvermogen en flexibiliteit: adapt, adaptation, adaptive. Verder gaat het vooral over waarde en waardes: de waarde die het product vertegenwoordigt voor opdrachtgever en gebruikers, en de waardes waar je als individu en organisatie aan hecht om het proces succesvol uit te voeren. 

De waarde van opgeleverde software is makkelijk uit te drukken in geld als het zich rechtstreeks vertaalt in hogere omzet of lagere kosten. Maar hoe geef je een cijfer aan een betere gebruikerservaring, een beter service, mooier ontwerp, stabielere code, laat staan een combinatie van al deze? Bedenk dat je ook de bouwers die die waarde creëren moet waarderen met meer dan een mooi salaris. Hoe weeg je af of een betere uitrusting voor het team of nieuwere technieken ook de moeite waard zijn als de eindgebruiker daar niet meteen iets van merkt? Wat dacht je van humane werktijden in plaats van een jaarlijkse death march om je release voor de Kerst in de winkels te hebben? Het debacle met Cyberpunk 2077 deze week laat zien hoe makkelijk je je reputatie om zeep helpt. De onmogelijke druk om de coolste game ooit vóór Kerst 2020 de deur uit te krijgen heeft de waarde van het aandeel CD Project Red gedecimeerd.

Zelfs de meest data-centrische CFO moet toegeven dat software maken draait om waarde optimaliseren op de lange termijn. Dat is best een onhandig vaag begrip voor een bedrijfstak die voortkomt uit de exacte wetenschap maar eigenlijk meer kunst dan wetenschap bedrijft – vaak met behulp van kunst en vliegwerk. Bovendien is er in software geen betrouwbare evenredige relatie tussen inspanning en opgeleverde waarde. Soms kun je de klant blij maken met een cruciale bug fix van een uurtje; een volgende keer heb je dat krediet hard nodig om de rekening van technische schuld weg te werken. In mijn IT-komedie Fair Trade foetert Volkert de opper-nerd de manager uit die extra handjes op het project wil: “Software maak je met je hoofd, niet met je handjes: we pellen hier geen garnalen!”. Was het maar zo simpel: twee keer zoveel handjes, twee keer zoveel garnalen, dubbele omzet.

Discussiëren over punten is zeker niet zinloos. We moeten immers een realistisch beeld krijgen van de relatieve grootte van de taken. Pas dan kan een product owner bepalen of de inspanning in verhouding staat tot de op te leveren waarde. Die waarde mag alleen hij of zij bepalen en niet de ontwikkelaars. Story points zijn nooit een uitdrukking van die waarde en daarom zijn ze ‘waardeloos’. Ook vanuit praktisch oogpunt moeten we er niet te veel waarde aan hechten. Als je te gebrand bent op het aftikken van een stabiel aantal punten per sprint gaan ze vanzelf lijken op ureninschattingen. 400 uren de laatste tien sprints? Veertig punten opgeleverd? Dat is dus tien uren per punt. Leg dan maar eens uit dat je ze eigenlijk als relatief moet zien.

Tenslotte ben ik van velocity al helemaal nooit een fan geweest. Ik vind het een verkeerd voorbeeld van een toch al twijfelachtig geloof in ‘meten is weten’. Wat zegt het als een team stilaan steeds dezelfde velocity haalt? Dat ze beter zijn geworden in het voorspellen van hun capaciteit. Of dat ze extra voorzichtig geworden zijn met hun commitment om maar niet aan de verkeerde kant van de streep terecht te komen. Always under-promise to over-deliver. Hoe dan ook zegt het nog steeds niks over de opgeleverde waarde. Die inschatting is een intuïtief proces dat alles in beschouwing neemt en een goede product owner is daarbij van onschatbare waarde.

23-12: kleine tekstuele wijzigingen; link naar Engelse versie.