Agile schatting: de complete gids

Planning Poker is een op consensus gebaseerde agile schattingstechniek: teams brengen in het geheim hun stem uit, leggen alle kaarten tegelijk open en bespreken de spreiding totdat de schattingen naar elkaar toe groeien.

Hoe u een planning poker-sessie organiseert die bruikbare schattingen oplevert zonder dat deze te lang gaat duren: voorbereiding, de ronde in vier fasen, het kiezen van een kaartspel en strikte tijdslimieten.

Storypoints geven de relatieve inspanning, complexiteit en onzekerheid van het werk weer — niet het aantal uren. Hoe u de omvang kunt bepalen ten opzichte van een referentiestory, en de vragen waar teams vaak over struikelen.

De story points stijgen van 1, 2, 3, 5, 8 naar 13, omdat de steeds grotere verschillen onzekerheid weerspiegelen — de schaal doet niet langer alsof u een 13 van een 14 kunt onderscheiden. Dit is waarom juist die verschillen de kern vormen.

Storypoints geven de relatieve inspanning weer; uren geven de duur weer — het zijn verschillende maatstaven. Als u een omrekeningstabel van punten naar uren opstelt, bent u stilletjes weer terug bij het inschatten van tijd.

Velocity is het gemiddelde aantal story points dat een team per sprint voltooit. Waarvoor het dient, waarom het niet meer werkt zodra het een doelstelling wordt, en hoe u ervoor kunt zorgen dat het een betrouwbare maatstaf blijft.

Mensen zijn slecht in het inschatten van ‘hoelang dit zal duren’ en goed in het beoordelen van ‘of dit groter is dan dat’. Bij relatieve inschatting wordt gebruikgemaakt van het tweede — en dat is de reden waarom story points zo goed werken.

Vroege schattingen lopen sterk uiteen omdat het werk nog onbekend is, niet omdat uw team slecht is in het maken van schattingen. Wat de ‘kegel van onzekerheid’ inhoudt, en hoe u deze kunt verkleinen — in plaats van deze nog groter te maken.

Epics, verhalen en taken vormen drie niveaus met elk drie functies. Wat elk daarvan inhoudt, welke verhaalpunten opleveren, en waarom het toekennen van punten aan het verkeerde niveau de velocity zinloos maakt.

Een vergelijking van agile schattingstechnieken — planning poker, T-shirt-sizing, buckets, dot voting, affinity en magic estimation, en de valkuilen die bij elk van deze methoden schuilgaan.

De veelvoorkomende manieren waarop Planning Poker-sessies mislopen — het berekenen van het gemiddelde van kaarten, schattingen in uren, ‘velocity’ als wapen, inflatie van story-points — en hoe u elk van deze problemen kunt verhelpen.

Acceptatiecriteria vormen de goed/fout-toets voor een story en worden opgesteld voordat met de werkzaamheden wordt begonnen — de formaten die geschikt zijn, uitgewerkte voorbeelden en hoe deze verschillen van de definitie van ‘klaar’.

De definitie van ‘klaar’ is een teambrede checklist waaraan elk verhaal moet voldoen voordat het wordt opgeleverd. Een voorbeeld van een DoD, wie hiervoor verantwoordelijk is en hoe deze verschilt van acceptatiecriteria.

De definitie van ‘gereed’ is de checklist die aangeeft of een story in de sprint kan worden opgenomen. Wat een nuttige checklist omvat, waarom de meeste worden genegeerd, en de versie die daadwerkelijk een belemmering vormt.

Een verhaal waarvan u de omvang niet kunt inschatten, is meestal een verhaal dat nog niet klaar is voor publicatie. Hoe weet u wanneer u het moet opsplitsen, welke scheidingslijnen tot publiceerbare delen leiden en welke slechts een schijnoplossing bieden?

SPIDR bestaat uit vijf betrouwbare manieren om een user story op te splitsen: spike, pad, interface, gegevens en regels. Wanneer werkt elke scheidingslijn, en wanneer levert deze een onjuiste opdeling op?

Verticale segmenten leveren waarde op; horizontale segmenten leveren beloften op. Waarom het opsplitsen per technologische laag de waarde uitstelt, en hoe u kunt segmenteren op basis van gebruikersresultaten, zodat er elke sprint iets wordt opgeleverd.

Een user story is een korte, in gewone taal geformuleerde belofte van toegevoegde waarde. De structuur ‘rol-doel-voordeel’, de drie C’s, de INVEST-checklist en de gevallen waarin user stories niet het juiste hulpmiddel zijn.

Zestien voorbeelden van user stories op het gebied van authenticatie, e-commerce, mobiele toepassingen, API’s en bugs — elk voorzien van toelichting, waarbij de onjuiste versies naast de herziene versies worden weergegeven, zodat het verschil duidelijk zichtbaar is.

Het klassieke sjabloon voor een user story met een kopieer-en-plak-kaart, de varianten die het vermelden waard zijn, en één uitgewerkt voorbeeld dat van het sjabloon via de acceptatiecriteria naar de schatting is doorgevoerd.