Mag het een onsje meer zijn?

Hoe groot mag een product backlog item zijn voordat een Developer team dit kan oppikken en ook daadwerkelijk in één sprint kan opleveren?

Met groot wordt met deze vraag vaak het aantal story points bedoeld. Eigenlijk begint het antwoord met de definitie van story points. Maar we slaan in deze post de scrum theorie over en gaan naar de alledaagse praktijk met een ander tintje theorie.

Story points toekennen aan product backlog items (PBI’s) gebeurd door het Developer team (dev team). De product owner (PO) legt een PBI voor aan het dev team, en zij geven een schatting op van de verwachtte benodigde werkinspanning om deze PBI te leveren volgens de huidige definition of done (DoD) en de acceptatie criteria (AC) bij dat PBI.

Het dev team mag kiezen uit de volgende verzameling getallen: ½, 1, 2, 3, 5, 8, 13, 21, 40, 100 en tot slot ? (en soms ook een break optie, zoals een koffiekopje – agile aanpak blijft dichtbij de echte mens). Deze reeks is geïnspireerd op de wiskundige fibonacci reeks, zie https://nl.wikipedia.org/wiki/Rij_van_Fibonacci voor het konijnen fokprogramma complot. Dit is niet zomaar een willekeurige reeks. Het bevordert en stimuleert diegenen die de schatting geven een duidelijke keuze te maken. Hoe groter de getallen, hoe verder de waarden uiteen liggen. Als het dev team de neiging krijgt een PBI groot in te schatten, dan hebben ze de keuze uit maar enkele waarden. Daarentegen, als ze een PBI nauwkeuriger kunnen inschatten, zullen ze ook een meer nauwgezette keuze moeten maken uit de lagere getallen, aangezien die dichter bij elkaar liggen. Het stimuleert dus om goed na te denken over de geschatte werkinspanning, want hoe nauwkeuriger de schattingen hoe geölieder de scrum machine loopt – noem er eens een handvol:

• Het team behaalt meer PBI’s per sprint.
• De PO is in staat transparanter te communiceren naar stakeholders.
• De PO is nog beter in staat de visie en strategie op korte termijn nog duidelijker te krijgen.
• De toegevoegde waarde van het product neemt daadwerkelijk toe per sprint.
• Er wordt minder technical debt opgebouwd.
• De mogelijkheid en acceptatie tot verandering blijf flexibel en gewaardeerd door het dev team.

Stel:

• We definiëren de mogelijke keuzes voor het dev team als een verzameling V met inhoud { ½, 1, 2, 3, 5, 8, 13, 21, 40, 100, ? }.
• V_length = 11.
• V_i = is de gekozen waarde door het dev team, waarbij i staat voor de index, het getal dat de positie aanduidt van de waarde in de verzameling, waarbij index 0 staat voor het eerste getal. (De laatste indexwaarde is dus gelijk aan V_length – 1.)
• Dan is de grootste kans op de werkelijke vereiste werkinspanning voor V_i een waarde tussen (V_i-1 + 1) ≤ V_i ≤ (V_i+1 – 1).

Voorbeeld:

• Het team kiest waarde 13, dat is V₆.
• De PO weet nu dat de grootste kans op afwijking van de schatting kan liggen tussen V₅ en V₇, waarden 9 en 20. Anders zou het team de PBI wel geschat hebben op 8 of 21.

Voorbeeld 2:

• Het team heeft een velocity van 40 story points per sprint.
• De PO weet nu dat als dit team twee PBI’s van elk 13 story points accepteren voor hun sprint planning ze misschien geen derde erbij moeten nemen. Elk PBI kan namelijk mogelijk 20 story points betekenen en daarmee opgeteld 40 in potentie kunnen zijn! En niet de slechts 13×2 is 26 punten.
• Als de 26 punten als uitgangspunt worden genomen, zal een PO het team graag nog meer PBI’s in de maag splitsen voor dezelfde sprint.
• In dit geval zal het toevoegen van één of twee kleinere PBI’s ter grootte van 2 prima erbij kunnen. Vooral als zij een lagere prioriteit hebben dan de twee grotere.
• Het opsplitsen van de 13 story points grote PBI zou in dit geval niet eens een onaardige aanpak zijn en zeker het overwegen waard moeten zijn voor zowel het dev team als de PO.

Kortom, wees er bewust van dat het altijd om een schatting gaat.

Het kan meevallen, leuk, en dus zorgt de PO ervoor dat er genoeg te doen is:

• Genoeg actionable PBI’s op de product backlog.
• Het liefst genoeg voor de komende drie sprints (ook met het ook op hele korte termijn visie, vakanties, ziektes, omgaan met nieuwe inzichten).

Het kan tegenvallen, dus zorgt de PO ervoor dat:

• De verwachtingen duidelijk worden gecommuniceerd naar de stakeholders.
• De sprint goal een duidelijk relatie heeft met de gekozen PBI’s.
• Er ruimte is in de sprint backlog voor tegenslag.