Tip: Onderaan dit blog vind je een begrippenlijst van alle Scrum-termen die ik in dit blog gebruik.
Planning poker. Het klinkt als een gezelschapsspel, maar vormt in feite de basis voor een efficiënte sprint. Hieronder lees je alles over hoe planning poker werkt én wat de voordelen ervan zijn.
Wat doen we tijdens de Sprint Planning?
Het succes van Scrum wordt voor een groot deel bepaald door de efficiëntie die ontstaat bij sterk afgebakende doelen. Dit afbakenen vormt dan ook de start van iedere sprint. Het hele scrumteam komt hiervoor samen voor de Sprint planning en bespreekt hierin:
- welke wensen iedereen de komende 2-3 weken (de komende sprint) wil realiseren;
- hoe het team die wensen (user stories) wil realiseren;
- en hoe complex het realiseren van elke wens is.
We bespreken dit aan de hand van planning poker. Het inschatten van de complexiteit van iedere wens (user story) levert veel transparantie op tussen de teamleden en product owner. Je weet zeker dat je op één lijn zit over wat er exact gedaan moet worden, én zorgt voor tijdswinst. Dikke tip Voordat je verder leest: in dit blog komen flink wat typische scrumtermen voor. Geen idee wat ze betekenen? Onderaan deze blog vind je een begrippenlijst.
De voorbereiding van planning poker
Voordat de sprint start, waarin het deelproject wordt gerealiseerd, zorgen de product owner (PO), de klant, en Scrum Master (procesbegeleider) samen voor een geprioriteerde backlog. In de backlog staan alle wensen van de klant beschreven, ook wel de userstories genoemd. Elke user story heeft van de PO een uniek nummer gekregen. Dit bepaalt de prioritering. De user story met het hoogste getal is dus het belangrijkste om te realiseren in die sprint. Voordat de Sprint Planning plaatsvindt zal de PO de backlog al doornemen met het development team. Dit geeft het team de mogelijkheid vragen te stellen en hiermee kan de PO de stories nog wat aanscherpen. Deze refinement vindt ongeveer een week voor de Sprint planning plaats.
Planning poker stap voor stap
1. Planning poker start bij de product owner. Die legt per user story uit aan het team wat exact de verwachtingen zijn.
2. Alle teamleden stellen nu voor de specifieke user story vragen vanuit hun eigen expertise om zo de ‘conditions of satisfaction’ scherper te krijgen. Op welke manier moet een bepaalde filter werken? Is er sprake van afhankelijkheden? Zo nodig wordt de user story scherper omschreven.
3. Nu is het moment van pokeren aangebroken. Het doel hierbij is het inschatten van de complexiteit per user story. Iedereen legt hiervoor een gesloten planning pokerkaart op tafel, met daarop een nummer: de zgn. story points. Dit nummer geeft de mate van complexiteit aan voor de werkzaamheden van het hele team. Eerder ingeschatte user stories gelden hierbij als referentiekader. Als alle kaarten op tafel liggen kunnen ze opengelegd worden.
4. De personen met het hoogste én het laagste nummer geven toelichting op hun keuze. Misschien verschillen de oplossingsmogelijkheden die ze voor ogen hebben? Door dit te bespreken, kan op voorhand de beste oplossingsrichting gekozen worden.
5. Tot slot wordt de definitieve hoeveelheid story points bepaald - eventueel nadat er opnieuw een inschatting is gemaakt. De product owner is degene die hierover de knoop doorhakt. Na stap 5 beginnen we opnieuw met stap 1, om de complexiteit van een ander onderdeel in te schatten. Afhankelijk van de complexiteit van een project, duurt de planning poker sessie van een sprint meestal tussen de 2 en 4 uur in totaal. Na de planning poker wordt door het development team aangegeven hoeveel story points zij verwachten in de sprint te kunnen verwerken. Deze stories vormen samen de Sprint Backlog.
Over de planning pokerkaarten
Ieder teamlid heeft een set van kaarten in handen. Deze kaarten bevatten een nummerreeks, afgeleid van de theorie van Fibonacci waarbij de ruimte tussen de getallen steeds groter wordt:
0 - 0.5 - 1 - 2 - 3 - 5 - 8 - 13 - 20 - 40 – 100
Hoe complexer een user story is, hoe groter de kans op tegenvallers. De regel is om bij twijfel altijd het hoogste cijfer te kiezen. Doordat de cijfers verder uit elkaar liggen naarmate de reeks oploopt bouw je een marge op voor tegenvallers.
Een voorbeeld
Stel: back-end developer Peter gooit 40 punten op en front-end developer Ronald legt 8 punten neer voor dezelfde user story. Dit verschil in puntenaantal kan verschillende oorzaken hebben. Misschien denkt Peter te omslachtig en heeft Ronald een efficiëntere oplossing. Of misschien denkt Ronald te makkelijk en ziet hij zaken over het hoofd. Een andere mogelijkheid is dat er 2 veschillende oplossingsrichtingen zijn, met ieder met hun eigen voordelen:
1 - De oplossing van Peter kost meer tijd maar levert meer conversie op.
2 - De oplossing van Ronald kost minder tijd maar gaat ten koste van de conversie.
In dit geval is het aan de product owner om hiertussen een keuze te maken.
Het is goed om te beseffen dat de nummers in sprint 1 nog niet zo veel zeggen - al zwengelen ze wel direct een waardevolle discussie aan. De kracht zit hem vooral in het vervolg. Na sprint 1 maak je namelijk de balans op en weet je hoeveel complexiteitspunten je in een sprint kunt oppakken. Heb je in sprint 1 120 story points afgekregen? Dan weet je bij de planning poker van sprint 2 dat je user stories tot een totaal van ca. 120 story points kunt inschatten.
De voordelen van planning poker op een rij
Planning poker kost met een compleet team gemiddeld 2 tot 4 uur. Dat is een aardige tijdsinvestering. Vaak vragen mensen zich af of dit niet zonde is. Wij geloven van niet. Onze ervaring is namelijk dat je de uren die je kwijt bent met planning poker, ruim terugwint in efficiëntie tijdens de sprint. Dat komt omdat:
- ieder teamlid dankzij het doorlopen van de user stories en de discussie die daaruit voortvloeit, tijdens de sprint exact weet wat er moet gebeuren;
- de klant aanwezig is bij het planning pokeren. Hierdoor begrijpt de klant beter welke wensen eenvoudig en welke complex zijn. Op basis hiervan kan de klant zijn of haar wensen eventueel anders prioriteren;
- het team op voorhand al plenair over de beste oplossingsrichting nadenkt. De oplossingsrichting hoeft dus niet op een later moment in het proces opeens herzien te worden.
Leer in een uur de basis van Scrum
Meld je aan voor ons gratis webinar en leer in één uur de basis van Scrum. Na dit webinar weet je wat Scrum is, hoe het werkt en kun je zelf aan de slag met de projectmethodiek.
Meld je gratis aan
Geen blogs missen uit deze serie?
Meld je hieronder aan voor onze e-mailupdates, waarbij je ook kunt aangeven welke onderwerpen je het meest interessant vindt. En lees mijn vorige blog in de serie over Sprint 0 - de belangrijke voorbereidingsfase binnen Scrum.
Begrippenlijst
- Sprint - Een iteratie van 2 of 3 weken, waarin een multidisciplinair team een set van wensen (user stories) oppakt.
- User story - Eén specifieke wens, op basis van een afgekaderde functionaliteit.
- Conditions of satisfaction - Per user story bepaalt het team wat er moet gebeuren om de user story af te kunnen ronden.
- Product backlog - De verzameling van wensen die in het product kunnen komen. Deze wensen (user stories) hebben allemaal een unieke prioriteit, op basis waarvan ze tijdens de sprints opgepakt worden. Dit zorgt ervoor dat een wens, hoe onrealistisch ook, altijd op de backlog kan staan - zolang de prioriteit maar klopt. Een backlog is overigens project overstijgend; wanneer na een half jaar een optimalisatiesprint gehouden wordt, is de (herziene) backlog hierbij nog steeds het uitgangspunt.
- Product owner - De afgevaardigde van de klant die bij het team op kantoor zit. De product owner kan ter plekke knopen doorhakken en vragen beantwoorden en houdt zo de vaart erin. Het is belangrijk dat de product owner hiervoor voldoende tijd en mandaat krijgt van de organisatie.
- Story points - Story points staan voor de complexiteit van een wens, geldend voor alle teamleden samen. Hoe meer user stories je inschat, hoe meer referentie je hebt om tot een goede inschatting te komen.