Planning Poker en Scrum Swimlane Sizing: een beknopte handleiding

In Scrum begint een Sprint altijd met de Sprint Planning meeting. Tijdens deze meeting is het hele Scrum Team aanwezig om een sprintdoel te bepalen en een plan te maken om dat sprintdoel te bereiken. Een belangrijk onderdeel van de Sprint Planning meeting is de inschatting door de Developers (voorheen het Development Team genoemd) van de hoeveelheid werk per User Story. Omdat mensen over het algemeen moeite hebben om de complexiteit en hoeveelheid inspanning van werk in te schatten wordt er door de Developers vaak gebruik gemaakt van Planning Poker of Swimlane Sizing. In dit artikel lees je hoe deze methodes werken.

Wat is de Reeks van Fibonacci?

Bij het inschatten van de hoeveelheid werk van een bepaalde User Story gaat het bij Swimlane Sizing en Planning Poker om de relatieve hoeveelheid van het werk ten opzichte van de andere User Stories. Hierbij wordt gebruik gemaakt van story points die zijn gebaseerd op een verdeling volgens de reeks van Fibonacci. De reeks van Fibonacci begint met 0 en 1 en vervolgens is elk volgende element van de rij steeds de som van de twee voorgaande elementen. De eerste elementen van de rij zijn dan als volgt: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144… Men laat de rij ook wel met 1 en 1 beginnen in plaats van 0 en 1.

Hoe werkt Swimlane Sizing?

Voor Swimlane Sizing heb je een tafel nodig waar de Developers omheen kunnen lopen. Maak op de tafel met behulp van tape 8 banen (“swimlanes”). Leg vervolgens ook alle User Stories voor de aankomende Sprint (vastgelegd op kaarten of post-its) op de tafel. De swimlanes worden (nog) niet genummerd.

Verdeel de User Stories onder de Developers en vraag of ze in de komende 5 minuten zonder overleg de User Stories in de swimlanes van klein (links) naar groot (rechts) willen plaatsen. Het is aan te bevelen om voordat iedereen begint 2 User Stories gezamenlijk te plaatsen zodat iedereen meteen een referentiekader heeft.

Nadat alle User Stories zijn geplaatst kijken de Developers zonder overleg in 5 à 10 minuten naar de verdeling van de User Stories en verschuiven deze waar nodig naar de juiste swimlane. Waarschijnlijk worden er User Stories door de Developers heen en weer geschoven. Zodra dat te vaak gebeurt wordt de betreffende User Story eruit gehaald. Aan het eind van deze ronde kan er worden overlegd over de User Stories die eruit zijn gehaald. Waarschijnlijk zal niet iedereen helemaal tevreden zijn, maar een zekere mate van consensus is wel vereist. Bij twijfel wordt er voor de grootste swimlane gekozen.

De Developers bepalen vervolgens of er een kleinere User Story zou kunnen bestaan dan de kleinste (in baan 1). Zo niet, krijgt deze eerste baan het nummer 1 of 2. Schat hierbij zelf in wat het beste past. Denken de Developers dat er wél kleinere User Stories mogelijk zijn, krijgt deze baan het cijfer 3 of 5. Vervolgens worden de rest van de swimlanes genummerd aan de hand van de reeks van Fibonacci. Als het goed is, is het voor de Developers nu inzichtelijk wat de hoeveelheid werk zal zijn voor alle User Stories.

Hoe werkt Planning Poker?

Bij Planning Poker krijgt elke Developer een set kaarten met de waarden 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 en 100. Vervolgens wordt er een User Story geselecteerd. Ieder teamlid legt vervolgens een kaart neer met een inschatting hoe groot of complex een activiteit volgens hem of haar is ten opzichte van voorgaande items. Er zitten regelmatig grote verschillen in de schattingen. De personen met de hoogste en laagste inschatting lichten hun keuze toe. Hierdoor worden de activiteiten meer concreet. Vervolgens start de volgende ronde en gooit iedereen opnieuw een kaart op, met in het achterhoofd de informatie uit de vorige ronde. Dit herhaalt zich totdat er overeenstemming is bereikt. Vaak is dit niet het gemiddelde, maar ligt de uitkomst dichter bij één van de uitersten. Blijft deze uitleg wat abstract? Hieronder geven we een voorbeeld.

In bovenstaand plaatje hebben twee Developers tijdens de Sprint Planning een User Story beoordeeld met 8 storypoints, terwijl twee andere teamleden denken dat de realisatie 5 storypoints kost. Omdat een User Story altijd volledig moet worden afgerond in een Sprint, wordt meestal de hogere inschatting gekozen. Zo verzeker je jezelf ervan dat je aan het eind van de Sprint een presenteerbare User Story hebt. Als het team vroegtijdig met alle items klaar is, dan kan gedurende de Sprint met de Product Owner worden overlegd om extra User Stories op te pakken.

Goed om te weten: een kaart met een vraagteken kan ingezet worden als iemand uit het Scrum Team geen inschatting kan of wil maken. Ook bestaat er een kaart met een koffiebeker. Pauzes horen er namelijk ook bij!

Het resultaat van Planning Poker is een door het team bepaalde Sprint Planning voor de betreffende Sprint. De voortgang van deze sprint wordt dagelijks bijgehouden op een Scrumbord. Zo is in één oogopslag te zien wat er nog gedaan moet worden, waar mensen mee bezig zijn en wat er gedaan is. Zo kan er tevens bepaald worden of er bijgestuurd moet worden.

Veel succes bij de volgende Sprint Planning! Voel je vrij om bij vragen contact op te nemen!

Ook interessant:

• De perfecte Sprint Planning meeting
• Scrum: het nut van een scrumbord
• Scrum training volgen? Bekijk het trainingsoverzicht.

Volg ons op LinkedIn (we delen onze blogs met je)