5.4 Relatief schatten: story points en planning poker

Kernbegrippen: story points, relatieve schatting, Fibonacci, planning
poker, referentiestory, T-shirtmaten, geen uren

Eerst de basis

Waarom niet gewoon in uren?

Mensen zijn slecht in het schatten van absolute duur en goed in het vergelijken. Welke
van deze twee taken is groter? Dat kunt u zien. Hoeveel uur ze kosten? Dat weet niemand, en uw
antwoord verandert met uw humeur en met wie het vraagt.

Story points drukken daarom de relatieve omvang uit: complexiteit, hoeveelheid
werk en onzekerheid samengenomen. Een story van 8 punten is ongeveer twee keer zoveel als een van
4 — niet acht uur.

Waarom een reeks met gaten

Geschat wordt vaak met een aangepaste Fibonacci-reeks: 1, 2, 3, 5, 8, 13, 20, 40, 100.
De gaten worden groter naarmate de getallen groter worden, en dat klopt met de werkelijkheid: bij
een groot item is het verschil tussen 20 en 21 zinloze precisie. Sommige teams gebruiken in plaats
daarvan T-shirtmaten (XS, S, M, L, XL).

Planning poker in vijf stappen

  1. De Product Owner licht het item toe; de Developers stellen vragen.
  2. Iedereen kiest in stilte een kaart — tegelijk onthullen, zodat niemand de ander
    volgt.
  3. Zijn de schattingen ver uit elkaar, dan lichten de hoogste en de laagste hun redenering toe.
    Dáár zit de informatie: meestal blijkt iemand iets te weten dat de rest niet wist.
  4. Een tweede ronde, en zo nodig een derde, tot de groep dicht genoeg bij elkaar zit.
  5. Lukt het niet: het item is te vaag of te groot. Terug naar refinement.
Begin met een referentiestoryKies een klein, goed begrepen item dat het
team al eens gedaan heeft en noem dat een 3. Alle andere schattingen worden daarmee vergeleken.
Zonder zo’n ijkpunt betekenen de punten van team A niets voor team B — en dat is precies waarom
u velocity nooit tussen teams mag vergelijken (zie 6.1).
Waar het vaak fout gaatStory points, planning poker en velocity staan
niet in de Scrum Guide; die zegt alleen dat de Developers de omvang bepalen. Verder:
punten zijn geen uren, ze zijn niet vergelijkbaar tussen teams, en ze horen nooit als prestatiedoel
gebruikt te worden — zodra dat gebeurt, worden ze opgeblazen en verliest u uw enige
planningshulpmiddel.