Story points versus #NoEstimates: ons oordeel

Geen van beide kampen wint onomstotelijk. Maak schattingen om tot een gezamenlijk begrip te komen en meningsverschillen aan het licht te brengen; maak geen schattingen om een datum te voorspellen — maak prognoses op basis van de doorvoer. We bekijken story points, #NoEstimates en de bedenker die zich van punten distantieerde vanuit het standpunt van de tegenstander, en trekken vervolgens onze conclusies.

Geen van beide partijen wint onomstotelijk. Maak een schatting om tot een gezamenlijk begrip te komen en meningsverschillen aan het licht te brengen; maak geen schatting om een datum te voorspellen — maak in plaats daarvan een prognose op basis van de doorvoer. Het cijfer zelf is vrijwel waardeloos. Het gesprek dat ertoe heeft geleid, is de echte meerwaarde.

Het debat wordt voorgesteld als een zwart-witkwestie — punten of geen punten — maar dat is het niet. Beide kampen hebben op een bepaald punt gelijk, en beide worden gesteund door een gezaghebbende autoriteit. Het nuttigste standpunt is datgene waarbij de sterkste argumenten van beide partijen worden bekeken en alleen die delen worden behouden die de toets der kritiek doorstaan.

De voordelen van story points

Het betoog van Mike Cohn, het toonaangevende standpunt van de voorstanders, ging nooit echt over het getal zelf. Het gaat erom dat juist het proces van het maken van relatieve schattingen een team dwingt om de complexiteit te bespreken, verborgen aannames aan het licht te brengen en overeenstemming te bereiken over wat een story daadwerkelijk inhoudt, voordat iemand code schrijft. Punten omzeilen ook een specifiek probleem: schat men in dagen, dan wordt er over elk getal onderhandeld; schat men in een abstracte eenheid, dan heeft het gekibbel geen houvast. Het addertje onder het gras is dat iedereen de knipoog opvangt – „we schatten geen tijd in, alleen complexiteit, zodat we de sprint kunnen plannen, die twee weken duurt“ – en de abstractie beschermt het team slechts zolang niemand deze direct weer omzet in een datum.

Steve McConnell vormt het rigoureuze tegenwicht voor de tegenstanders van het maken van schattingen. Zijn stelling is dat de hoofdoorzaak van slechte schattingen doorgaans een gebrek aan vaardigheid op het gebied van schatten is, en niet het schatten zelf — en dat serieuze schatters drie zaken onderscheiden die in het debat steeds door elkaar worden gehaald: de schatting (wat waarschijnlijk is), de doelstelling (wat het bedrijf wil) en de toezegging (wat het team belooft). Als u deze door elkaar haalt, lijkt het schatten natuurlijk niet te werken. Houdt u ze echter gescheiden, dan levert het daadwerkelijk resultaat op.

De argumenten voor #NoEstimates

Nu de andere kant, in volle kracht. Het bezwaar van Allen Holub is dat schattingen altijd onnauwkeurig zijn, meestal zelfs schromelijk, en dat story points bedoeld waren om de duur te verdoezelen, zodat managers zouden stoppen met druk uit te oefenen op de tijd — maar teams rekenen ze direct weer om naar uren, waardoor ze precies die disfunctionele situaties opnieuw creëren die met de invoering van story points juist moesten worden voorkomen. De Fibonacci-schaal biedt geen uitkomst als iedereen stiekem een omrekeningstabel van punten naar uren bij de hand heeft.

De meest treffende opmerking met betrekking tot gegevens komt van Vasco Duarte: bij echte projecten levert het simpelweg tellen van stories ongeveer even goede voorspellingen op als het optellen van hun storypunten. Als dat ook voor uw werk geldt, zijn de punten louter een formaliteit — u hebt rekenwerk verricht om tot hetzelfde antwoord te komen dat het tellen u al had gegeven. Meet in plaats daarvan de doorvoer en de cyclustijd; een groeiende wachtrij is een voorlopende indicator die u van tevoren kunt zien aankomen, terwijl de velocity een achterblijvende indicator is.

En toen kwam de meest treffende opmerking van het hele debat. Ron Jeffries, die algemeen wordt gezien als de uitvinder van story points, nam zijn woorden in 2019 terug: „Ik heb story points misschien wel uitgevonden, en als dat zo is, spijt het me nu.” Zijn bezwaar betreft met name het gebruik ervan om te voorspellen wanneer het werk voltooid zal zijn en om teams met elkaar te vergelijken. Zijn alternatief is niet „stop met plannen“ — het is het opdelen van stories in stukken die zo klein zijn dat er slechts één acceptatietest voor nodig is, idealiter elk minder dan een dag, zodat er nauwelijks nog iets overblijft om in te schatten.

In welke gevallen wij van gedachten zouden veranderen

Wij zouden volledig voor #NoEstimates kiezen voor een team waarvan het werk al in kleine, uniforme delen is opgedeeld. Zodra elke story ongeveer een dag in beslag neemt, het tellen van stories en het optellen van punten volstaat, en de schattingsvergadering een overbodige last is die u kunt schrappen — McConnell geeft dit toe en noemt werk in snelle cycli, waarbij de missie simpelweg „het volgende meest nuttige doen“ is, als een context waarin schattingen weinig toevoegen.

In het tegenovergestelde geval zouden wij onze waakzaamheid ten aanzien van punten wat laten verslappen: een organisatie waar schattingen werkelijk nooit uitgroeien tot vaste toezeggingen en niemand teams met elkaar vergelijkt. Daar bestaat het gevaar waarvoor het anti-schattingskamp waarschuwt niet, en zijn punten slechts een onschadelijke aanleiding voor een gesprek. Het probleem is dat een dergelijke organisatie zeldzaam is. Het misbruik ervan is de norm, en dat is de reden waarom ons oordeel in deze richting neigt.

De praktische kant van de zaak

one story 3 13 one dev another dev the gap is the point talk it out — don’t average A 3 beside a 13 means you’re picturing different work.
Het resultaat van Planning Poker is niet het getal, maar het verschil. Een 3 naast een 13 betekent dat twee mensen een verschillend beeld hebben van het werk — breng dit via een gesprek op één lijn; ga niet voor een compromis.
  • Beschouw planning poker als een middel om meningsverschillen aan het licht te brengen, niet als een voorspellingsinstrument. Een 2 en een 13 voor hetzelfde verhaal vormen het signaal — dit betekent dat het team geen gemeenschappelijk begrip heeft van het werk. Blijf overleggen totdat het verschil tussen de scores verdwijnt; overeenstemming is het eindresultaat, niet het uiteindelijke getal.
  • Maak prognoses op basis van doorvoer en cyclustijd, niet op basis van het totaal aantal punten. Velocity dient als planningsinput voor het team, en is geenszins een toezegging aan derden.
  • Maak een onderscheid tussen een schatting en een toezegging, zoals Cohn zegt. Een schatting is een gok; op het moment dat het een belofte wordt, heeft iemand de betekenis ervan veranderd zonder het team hiervan op de hoogte te stellen.
  • Als u punten gebruikt, houd ze dan relatief. Zodra u ze aan uren koppelt, bent u in feite de duur aan het schatten — met alle druk die bij urenschattingen hoort, plus een extra laag van onduidelijkheid.
  • Verdeel het verhaal in stukken in plaats van de omvang ervan te bepalen. Jeffries heeft gelijk dat het grootste deel van de waarde waarover in het debat wordt gestreden, verdwijnt wanneer verhalen zo klein zijn dat de schatting nauwelijks nog van belang is.

Het getal is zinloos; het gaat om het gesprek dat eraan ten grondslag ligt. Die ene zin lost het grootste deel van het geschil op — en zorgt ervoor dat een planning poker-sessie daadwerkelijk nuttig blijft, zonder te doen alsof men de toekomst kan voorspellen.

Veelgestelde vragen

Moeten we story points gebruiken of #NoEstimates?

Gebruik de methode die het gesprek over de schatting op gang brengt, en beschouw het getal niet langer als een voorspelling. Storypoints zijn nuttig als indicator voor meningsverschillen — een grote spreiding bij één verhaal betekent dat het team er geen gemeenschappelijk begrip van heeft. #NoEstimates is de juiste keuze wanneer uw stories al in kleine, uniforme delen zijn opgedeeld, omdat het tellen ervan dan zowel een prognose oplevert als een optelling van punten. Hoe dan ook: maak een prognose van de oplevering op basis van de doorvoer, en maak een onderscheid tussen het maken van schattingen en het aangaan van toezeggingen.

Heeft de bedenker van story points deze werkelijk afgezworen?

Ron Jeffries, die algemeen wordt gezien als de bedenker van story points, schreef in 2019: „Ik heb story points misschien wel uitgevonden, en als dat zo is, spijt het me nu.” Zijn bezwaar betreft het gebruik ervan om opleveringsdata te voorspellen en om teams te vergelijken of te beoordelen. Het door hem aanbevolen alternatief is niet „geen planning“ — het is het opsplitsen van stories in stukken die zo klein zijn dat er slechts één acceptatietest voor nodig is.

Hoe kunt u een release plannen zonder elke story in te schatten?

Meet de doorvoer — het aantal stories dat het team daadwerkelijk per week afrondt — en maak op basis van dat tempo een prognose van de resterende backlog. Vasco Duarte heeft vastgesteld dat het tellen van stories ongeveer even goed werkt voor prognoses als het optellen van storypunten; zodra de stories dus in stukken van vergelijkbare omvang zijn verdeeld, voegen de punten weinig extra informatie toe die het tellen niet al biedt.

Aanbevolen lectuur