DevelopmentIs dit Scrum? – Planning Poker

Planning Poker wordt door veel mensen gezien als een belangrijk onderdeel van Scrum. Het is echter geen onderdeel van het Scrum Framework.

In deze serie van blogs ga ik in op verschillende praktijken die door velen al gezien worden als onderdeel van Scrum, maar dit officieel niet zijn. Mijn vorige blog ging over user stories. Dit keer ga ik in op planning poker. De aanleiding hiervoor is dat de vraag om planning poker uit te leggen vaak één van de eerste dingen die ik hoor ik tijdens Scrum trainingen.

Scrum is als framework inmiddels bekend. Doordat veel bedrijven toch hun eigen draai geven aan het framework en de praktijken eromheen, zie ik echter een verbastering ontstaan van de termen die gebruikt worden. Het zijn vaak (goede) invullingen van of toevoegingen aan het framework. Ik leg dat vaak uit aan de hand van een analogie. Vergelijk Scrum met een kleurplaat, de lijntjes staan vast, maar de invulling (of kleur) is door elke organisatie zelf te bepalen. Het Scrum framework zelf verandert hierdoor niet.

Planning poker

Planning poker wordt gebruikt binnen het refinement proces en is bedoeld om de relatieve grootte van User Stories in kaart te brengen. Het proces is ontstaan in 2002 en door Mike Cohn in groot gebruik geraakt via zijn boek Agile Estimating and Planning. Nu geven bedrijven hun eigen set pokerkaarten weg zodat elk team snel en makkelijk kan starten met planning poker.

Planning poker is een methode om na een ge-timeboxte discussie* iedereen een kaart met een cijfer omhoog te laten houden om te zien of iedereen op één lijn zit over hoeveel inzet het kost om een user story te verwerken in werkende software.

*Een ge-timeboxte discussie wordt gebruikt om in korte tijd te bespreken wat de user story moet gaan opleveren en door het te timeboxen zorg je ervoor, dat de focus op dit ene onderwerp blijft.

Het werkt als volgt:

Ieder teamlid geeft zijn inschatting van de grootte is ten opzichte van andere user stories door de kaart met het desbetreffende cijfer te laten zien. Daarna volgt een discussie over de eventuele verschillen. Een bekend voorbeeld is een User Story die voor een programmeur misschien een kleine aanpassing is, maar voor een tester betekent dat er veel scenarios getest moeten worden.

Planning Poker
Voor het toekennen van story points wordt gebruik gemaakt van de schaal van Fibonacci. Deze reeks is bewust gekozen, om duidelijk te maken, dat er verschillen zijn tussen de stappen. Hoe hoger het getal, hoe groter de stapnaar het volgende getal wordt. Dit omdat het steeds moeilijker wordt een inschatting te maken, naarmate het in te schatten object groter is.
Als er grote verschillen zijn tussen de inschattingen, is dat een goed moment om de discussie weer aan te zwengelen. Het team zit kennelijk nog niet op één lijn over de inzet die nodig is om de User Story te maken. We moeten dus goed bespreken waar die verschillen vandaan komen en wat iemand heeft gemist. Het kan zijn dat iemand het werk onderschat, maar ook dat iemand denkt dat er werkzaamheden gevraagd worden, die totaal niet nodig zijn. Het uiteindelijke doel van planning poker is dat het team een gezamenlijk beeld krijgt van de omvang van een user story. Dat kan alleen als iedereen het ook eens is wat er moet gebeuren om de user story om te zetten naar een werkend product.

Maarrr…

Net als bij User stories is ook het gebruik van planning poker gemeengoed geworden binnen Scrum. De essentie, waarom je er gebruik van maakt, is echter verloren gegaan.

Ik zie vaak, dat teams wel een discussie hebben over een user story en op een gegeven moment de kaarten erbij pakt om de story ete ‘pokeren’. Bij verschillende waarden mogen de hoogste en laagste nog snel hun mening geven en dan wordt er opnieuw gepokerd zodat iedereen ongeveer dezelfde kaart ophoudt.
Er wordt snel een compromis gezocht, zodat men door kan naar de volgende story. Hier wordt het toekennen van story points aan een user story gezien als de laatste stap van de “definition of ready” of nog erger: het doel voor deze user story is gehaald want we hebben er punten aan gegeven.
Het is prettig als iedereen ongeveer dezelfde inschatting geeft, al hoeft dat niet om dezelfde redenen te zijn. Vervelender is het, als mensen toegeven om maar klaar te zijn met refinement.

#Noestimates

Niet iedereen is enthousiast over Planning poker. Zij bijvoorbeeld het initiatief: “No estimates” Het idee achter #noestimates is, dat het inschatten van werk “waste” is en alleen maar tijd kost. Doordat teams zo bezig zijn met het inschatten van user stories, ligt de focus niet meer op opleveren van waarde, maar alleen nog naar het inschatten van de effort. Als je dan bedenkt dat deze story points vaak ook nog een eigen leven gaan leiden, zorgt dat voor nog meer “waste” omdat men nu beslissingen gaat baseren op verkeerde informatie.

Conclusie

Planning poker is een geschikt middel om binnen een team te komen tot een gezamenlijk beeld van wat er gedaan moet worden. Het mag echter nooit een einddoel zijn. Het is een middel om binnen het refinement proces tot een gezamenlijke inschatting te komen. Als er kaartjes met uiteenlopende cijfers getoond worden, is dat een duidelijke indicatie dat het beeld nog niet gedeeld wordt. Planning poker is zeker niet een onderdeel van Scrum zelf, het is een manier om tot een inschatting van hoeveelheid werk te komen.

Dus het oordeel: Geen officieel onderdeel van Scrum, maar voor veel teams wel een goede manier om een gemeenschappelijk beeld te krijgen van de inhoud van de product backlog.

Vind u het leuk om te sparren over onderwerpen rondom scrum en agile? Vier keer per jaar organiseren wij een Scrum Round Table waarin we elke keer ingaan op een ander onderwerp.

Alex Roos, DevOps Consultant