Het juiste moment voor Planning Poker

Planning Poker is een schattingsmethode die gebaseerd is op consensus. Daarom raad ik aan om het ook te gebruiken voor items die consensus vereisen – dus eerder voor Product Backlog Items dan voor taken in een Sprint Backlog. In dit artikel ga ik nog eens in op Planning Poker en leg ik uit wanneer je het zou moeten toepassen.

Redenen voor het inschatten van User Stories

Het inschatten van User Stories in een Product Backlog heeft twee redenen:

1.) De Product Backlog kan geprioriteerd worden. Stel je twee Product Backlog Items voor die de Product Owner als gelijkwaardig beschouwt. Het item met de laagste kosten wordt dan als eerste opgepakt. De waardering van items hangt dus af van hun kosten en kan zo gebruikt worden voor de prioritering.

2.) Het bedrijf kan voorspellingen op langere termijn doen. De omvang van het werk moet bekend zijn, zodat de Product Owner kan aangeven wanneer hoeveel opgeleverd kan worden.

Wanneer moet je Planning Poker spelen?

Met behulp van de bovengenoemde punten kun je bepalen wanneer een team inschattingen zou moeten maken. Enerzijds moet het vroeg genoeg gebeuren om aan beide voorwaarden te kunnen voldoen. Anderzijds moet het niet eerder dan strikt noodzakelijk gebeuren.

In de praktijk zijn er twee situaties waarin een team Planning Poker zou moeten spelen.

Een goed moment voor Planning Poker is bijvoorbeeld na een Story Writing Workshop, waarin veel Product Backlog Items zijn aangemaakt. Deze workshops zouden ongeveer elk kwartaal gehouden moeten worden.

Zo kunnen de Product Owner en het team een groter doel vaststellen (dat niet in één enkele Sprint bereikt kan worden) en de daarvoor benodigde User Stories aanmaken.

Doorgaans ontstaan er bij een driemaandelijkse Story Writing Workshop 20 tot 50 Product Backlog Items. Als je ongeveer 20 items per uur kunt inschatten, heb je voor het inschatten in totaal misschien twee uur per kwartaal nodig.

Daarnaast kan Planning Poker ook eenmaal per Sprint worden uitgevoerd. Sommige teams doen dit tijdens de reguliere Product Backlog Grooming Meeting. Dat is helemaal prima – zolang alle teamleden erbij betrokken zijn.

Als niet alle teamleden daarbij betrokken zijn, kun je Planning Poker ook na een Daily Standup tegen het einde van een Sprint uitvoeren. Als een team te vroeg tijdens een Sprint inschattingen maakt, kan het zijn dat je alles opnieuw moet doen voor Stories die later worden toegevoegd.

Maar de inschatting moet ook niet te laat plaatsvinden. Dan kan de Product Owner deze items namelijk niet meenemen bij het vaststellen van de items voor de volgende Sprint.

Wanneer moet je Planning Poker niet spelen?

Er is één moment dat ongunstig is voor Planning Poker: aan het begin van een Sprint Planning Meeting. Op dat moment is het namelijk te laat voor de Product Owner om de nieuwe inschattingen mee te nemen bij het stellen van prioriteiten.

Er zijn misschien Product Owners die in no time de prioriteiten opnieuw kunnen ordenen. Maar meer tijd hebben is altijd beter.

Een ander probleem is dat een team bijna altijd te veel tijd besteedt aan het inschatten wanneer een Sprint Planning begint met Planning Poker. Ik denk dat dit komt doordat de teamleden dan al meteen gaan nadenken over de details van hun User Stories.

Bij Planning Poker zouden ze eigenlijk een minder gedetailleerde inschatting van hun User Stories moeten geven. Het is lastig om in een meeting zo'n grove inschatting te geven, wanneer je de Tasks eigenlijk veel nauwkeuriger zou moeten beoordelen.

Dit leidt tot onnodig veel discussies. En dat zorgt er weer voor dat het team veel langer nodig heeft dan wanneer je beide apart zou uitvoeren.

Met deze richtlijnen zou je in staat moeten zijn om het juiste moment voor Planning Poker te vinden.

Deze tekst is afkomstig van de blog van Mike Cohn en is door ons vertaald naar het Duits.