Agile schatting: de complete gids
Een praktische gids voor agile schattingen: user stories, planning poker, story points, velocity en de technieken die hun waarde behouden wanneer een user story omvangrijker blijkt te zijn dan aanvankelijk leek.
Schattingen lopen vaak op de gebruikelijke manieren mis: cijfers die voor verschillende mensen verschillende betekenissen hebben, sessies die uitlopen, prognoses waar niemand op vertrouwt. De oplossing ligt zelden in een betere formule — het gaat om een gedeeld begrip waar het hele team zich achter schaart, en om schattingen die als prognoses worden beschouwd in plaats van als toezeggingen die u later worden aangerekend.
In deze handleiding worden de onderdelen behandeld die in de praktijk hun waarde bewijzen: user stories, planning poker, story points, velocity en de technieken die blijven werken wanneer een story omvangrijker blijkt te zijn dan aanvankelijk leek. Wanneer u klaar bent om met uw team een schatting uit te voeren, schat dan in TeamRetro: planning poker met anonieme stemming, herbruikbare kaartspellen en definitieve story points die direct met uw backlog worden gesynchroniseerd.
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 convergeren.
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 van een project kunt bepalen aan de hand van een referentieverhaal, 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.
Ontdek wat teamvelocity is binnen agile, hoe u dit kunt berekenen en hoe u hiermee sprints kunt plannen, inclusief een gratis velocity-calculator.
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 taken. Wat elk daarvan inhoudt, welke verhaalpunten opleveren en waarom het toekennen van punten aan het verkeerde niveau de velocity zinloos maakt.
Een praktische handleiding voor het kiezen van agile schattingstechnieken: planning poker, story points, t-shirt sizing, affiniteitsschatting en velocity, en wanneer u welke techniek het beste kunt toepassen.
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 verhaal 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 leidt deze tot een onjuiste opdeling?
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.
Wat de T-shirt-maatvoering inhoudt, hoe u een sessie leidt en hoe u S/M/L omzet in story points, plus wanneer planning poker de betere keuze is.