slim
samen
werken

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 van het Ontwikkelteam 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 Ontwikkelteams vaak gebruik gemaakt van Planning Poker of Swimlane Sizing. In dit artikel lees je hoe deze methodes werken.

Scrum Poker

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 storypoints 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.

scrum trainingen

Swimlane Sizing

Voor Swimlane Sizing heb je een tafel nodig waar het Ontwikkelteam omheen kan 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.

swimlane sizing

Voorbeeld van 8 swimlanes

Verdeel de User Stories onder de Ontwikkelteamleden 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.

swimlane sizing

Nadat alle User Stories zijn geplaatst kijkt het Ontwikkelteam zonder overleg in 5 à 10 minuten naar de verdeling van de User Stories en verschuift deze waar nodig naar de juiste swimlane. Waarschijnlijk worden er User Stories door Ontwikkelteamleden 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.

Het Ontwikkelteam bepaalt 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. Denkt het Ontwikkelteam 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 het Ontwikkelteam nu inzichtelijk wat de hoeveelheid werk zal zijn voor alle User Stories.

De laatste swimlane kan eventueel dienen voor alles wat groter is dan 40 storypoints

Planning Poker

Bij Planning Poker krijgt elk Ontwikkelteamlid 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.

Planning Poker

In bovenstaand plaatje hebben twee Ontwikkelteamleden 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.

Agile Marketing Kanban

Scrumbord

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

Ook interessant:

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

LINKEDIN
Follow by Email
Schrijf je in om om de week de nieuwste Agile inzichten te ontvangen