Schattingen behoren tot de meest controversiële onderwerpen binnen productontwikkeling. Waarom? Omdat teams bang zijn aansprakelijk te worden gesteld voor cijfers die per definitie onzeker zijn. Sommigen bouwen buffers in om zichzelf te “beschermen”; anderen vinden het zinloos om complexe werkzaamheden in te schatten.
Het doel van relatieve schatting is eenvoudig: betere gesprekken over het probleem. De taak van de Product Owner is om het rendement op de investering (ROI) te maximaliseren door de bedrijfswaarde af te wegen tegen de omvang en complexiteit van het werk. De vraag is: “Hoeveel rendement kan ik uit deze investering halen?” Relatieve waardering biedt een antwoord op beide aspecten van die vergelijking: waarde en investering.
Planning Poker is de faciliteringstechniek die dit mogelijk maakt. Deze techniek zorgt ervoor dat de mening van elk teamlid meetelt, terwijl het proces toch effectief blijft. Teams gebruiken fysieke kaarten of smartphone-apps met een Fibonacci-achtige reeks: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? – en ☕.
Planning Poker kan worden gebruikt door teams en hun Product Owner om een inzicht in de investering, en het kan door de Product Owner worden gebruikt in overleg met belanghebbenden om afstemming te bereiken over de verwachte bedrijfswaarde. Voor beide groepen verloopt het proces op dezelfde manier.
Waarom relatieve schattingen zinvol zijn
Teamleden aarzelen vaak om schattingen te maken, omdat hun cijfers als vaste toezeggingen worden beschouwd – ongeacht de aannames of onverwachte ontwikkelingen die zich later voordoen. Om zichzelf te “beschermen”, voegen ze buffers toe of vermenigvuldigen ze schattingen met een factor (soms π, om het er wetenschappelijk uit te laten zien). Maar het opstapelen van buffers vermindert de transparantie en maakt schattingen nutteloos.
Het opstellen van nauwkeurige schattingen kost tijd, maar die extra inspanning loont zelden de moeite. Schattingen zullen nooit 100% nauwkeurig zijn, dus als je minder tijd besteedt aan het maken van schattingen en meer tijd aan het leveren van het eindresultaat, levert dat vaak betere resultaten op. Bij relatieve schatting wordt hier rekening mee gehouden: het gaat om omvang en complexiteit, geen uren. We noemen dit verhaalpunten.
Bij relatieve schatting hoef je niet precies te zijn; je hoeft alleen maar consistent te zijn in hoe slecht je schattingen zijn. Tegelijkertijd helpt relatieve schatting teamleden om hun inzichten in de uit te voeren taak te delen en het eens te worden over de omvang ervan.
Hoe komt dat?
Het zit namelijk zo: Peter, Paul en Mary zijn niet allemaal even bedreven in het uitvoeren van bepaalde taken. Sommige taken kan Peter sneller uitvoeren dan Paul – omdat hij op dat gebied meer ervaring heeft. Bij andere taken is Paul sneller dan Mary – en bij weer andere taken is Mary de snelste. Tegelijkertijd variëren Mary's motivatie en energie – de ene dag is ze vol energie, de andere dag is ze bijna op. Misschien heeft ze vannacht niet goed geslapen. Op de dagen dat ze vol energie zit, krijgt ze veel voor elkaar; op de dagen dat dat niet zo is, gaat het werk nauwelijks van de grond. Mensen zijn geen robots. Ons werk verloopt niet lineair – interacties en output variëren.
Om dit in evenwicht te brengen, gebruiken we story points. Met story points kunnen Peter, Paul en Mary het erover eens zijn dat de ene taak een 5 is, een andere een 13 en een derde een 8 – zelfs als Peter het beste is in de eerste, Mary in de tweede en Paul in de derde. Is het een exacte wetenschap? Nee. Maar op den duur compenseert het zich. Het is net als op de schommel: soms win je, soms verlies je. Het inschatten van complex werk is nooit een exacte wetenschap geweest – en zal dat ook nooit worden.
Om story points los te koppelen van tijd, moet het team beschikken over een verwijzing op basis van werk dat ze al hebben gedaan – we noemen dit doorgaans ‘user stories’. Ze stellen dit referentiekader op door verschillende werkitems met elkaar te vergelijken. Welk item is een 3, welk item een 5 en welk item een 8? Het team moet dit referentiekader in de loop van de tijd bijhouden en verfijnen, en er tegelijkertijd voor zorgen dat het referentiekader niet afwijkt van de oorspronkelijke bedoeling.
Een metafoor om story points te begrijpen
Neem eens een eenvoudige taak: een hoop zand verplaatsen. De twee mensen die deze taak gaan uitvoeren, kunnen het grofweg eens worden over het volume (de omvang) ervan – en ze kunnen het ook eens worden over de complexiteit van het verplaatsen ervan. Eerlijk gezegd is het verplaatsen van zand niet zo complex – tenzij het zand vervuild is, wat de klus ingewikkelder maakt omdat er dan speciale handelingen en apparatuur voor nodig zijn.
De klus om het zand te verplaatsen heeft een bepaalde combinatie van omvang en complexiteit – we zouden kunnen zeggen dat deze klus een 8 is. Als het vervuild zand was geweest, was het misschien een 13 of een 20 geweest. Toch zegt dit niets over hoe lang het zal duren. Dat hangt af van hoe de klus wordt bemand. Als één persoon het zand verplaatst, kost dat een bepaalde tijd; als twee mensen het doen, zal de tijd anders zijn (hopelijk korter). Misschien zijn de twee mensen niet even bedreven in het verplaatsen van zand. Misschien heeft één van hen last van zijn rug – dan duurt het langer als die persoon alleen werkt. Als de andere persoon het doet, gaat het sneller. Misschien varieert het gereedschap – de ene dag gebruiken ze emmers, de andere dag kruiwagens en op een derde dag een graafmachine. De tijd zal variëren, maar de combinatie van omvang en complexiteit blijft hetzelfde. Het blijft een 13, ongeacht hoeveel mensen de klus doen of welk gereedschap ze gebruiken.
Het is geen exacte wetenschap, maar op de lange termijn komt het wel in evenwicht – vooral als je de referentie en het team stabiel houdt.
Hoe te spelen
Aan het begin van Planning Poker krijgt elk teamlid een stapeltje kaarten. Voor elke user story of elk thema dat moet worden ingeschat:
- Een moderator – meestal de Product Owner, Scrum Master of een analist – leest de beschrijving voor. De de moderator stemt niet mee.
- Elk teamlid kiest in stilte een kaartwaarde op basis van hun begrip van het verhaal, wanneer ze dit vergelijken met de verwijzing die het team heeft gemaakt.
- Als iedereen een keuze heeft gemaakt, worden alle kaarten tegelijkertijd omgedraaid.
- De teamleden met de hoogste en laagste waarden hun redenering toelichten.
- De Product Owner of belanghebbende beantwoordt eventuele vragen van het team.
- Elk teamlid herberekeningen door in de privémodus een nieuwe kaart te kiezen.
- Alle kaarten worden opnieuw weergegeven, zodat iedereen de bijgewerkte schattingen kan zien.
- De teamleden met de hoogste en laagste waarden hun redenering bespreken nogmaals.
- Na de bespreking maakt elk teamlid nogmaals een schatting van de definitieve doorlooptijd.
- Als er slechts een verschil van één stap tussen de overgebleven kaarten, de de hoogste waarde wordt gekozen.
- Als er na de derde ronde is er nog steeds geen overeenstemming, de de hoogste waarde wordt gekozen.
Planning Poker inzetten voor bedrijfswaarde
Hetzelfde geldt voor de bedrijfswaarde. Hier voeren de Product Owner en de betrokken stakeholders de relatieve inschatting uit. Net zoals het team een referentiekader heeft voor story points, moeten de Product Owner en de stakeholders een referentiekader hebben voor bedrijfswaarde – bij voorkeur functies die hun waarde al op de markt hebben bewezen.
Tijdens de begroting moet hun dialoog over bedrijfswaarde verder gaan dan alleen geld. Ze zouden bijvoorbeeld het volgende kunnen bespreken:
- Zal deze functie nieuwe mogelijkheden bieden? nieuwe markten voor ons?
- Kan het ons helpen? upsell aan bestaande klanten?
- Is dit nodig om behouden onze marktpositie?
- Zal het beter worden? efficiëntie?
- Wordt dit vereist door wetgeving?
- Zal het onze merk?
Geen van deze aspecten is op zich beter dan de andere, maar het gaat om de discussie en de afstemming.
Relatieve schatting gebruiken voor prognoses
Het doel van het maken van schattingen is om voorspelbare plannen op te stellen. Dat is bijna onmogelijk bij complexe werkzaamheden – maar dat mag ons er niet van weerhouden om het in ieder geval te proberen. Hoe Agile we onszelf ook vinden, er blijft behoefte aan synchronisatiepunten zoals mijlpalen of gates. Andere afdelingen – zoals productie, verkoop of marketing – zijn erop aangewezen te weten wanneer we klaar zijn met het ontwikkelen van een functie of product. Ook al zullen plannen veranderen, moeten we toch onze beste inschatting geven van wat er zal gebeuren en wanneer we klaar zijn.
Door gebruik te maken van relatieve schattingen met story points en door te meten hoeveel story points het team in elke sprint oplevert (hun velocity), kan de Product Owner nogal voorspelbare plannen. Dankzij de bereidheid van het team om items in de Product Backlog in te schatten – ook al zijn ze slechts kort beschreven – wordt het voor de Product Owner een eenvoudige taak om in kaart te brengen welke items waarschijnlijk in welke sprints passen. Dit zorgt voor transparantie over plannen en voortgang, waardoor het Product Owner-team prioriteiten met belanghebbenden kan bespreken en de best mogelijke beslissingen kan nemen.
De grootste uitdaging bij het gebruik van snelheid is dat deze in de loop van de tijd varieert. Hierop zijn verschillende factoren van invloed:
- Beschikbaarheid van teamleden voor samenwerking
- Verstoringen in het dagelijkse werk
- Verschillen in de mate waarin de competenties van het team aansluiten bij de huidige taken
- De toewijding en inzet van de teamleden om de Sprint Goal te behalen
Een goede manier om met deze onzekerheid om te gaan, is door gebruik te maken van de 90% Betrouwbaarheidsinterval van de snelheid. Hoewel hier statistische formules aan ten grondslag liggen, gebruik je in de praktijk de de op één na hoogste en de op één na laagste snelheid op basis van de laatste acht sprints om het interval te bepalen waarop de toekomstige snelheid moet worden afgestemd.
Sommige teams bouwen in de sprint een buffer in voor onvoorziene werkzaamheden. Het gebruik van relatieve schattingen met story points en het baseren van toezeggingen en prognoses op de gemeten velocity betekent echter met deze buffer is al rekening gehouden. Als een team werk opneemt op basis van zijn huidige snelheid, is de benodigde buffer dan al automatisch inbegrepen.
Het is geen exacte wetenschap, maar op de lange termijn komt het wel in evenwicht – vooral als je de referentie en het team stabiel houdt.
Laatste gedachten
Het gebruik van relatieve schattingen biedt een eenvoudige manier om je weg te vinden in de complexiteit van productontwikkeling in de moderne wereld. Het vermogen om dit te doen komt echter niet zomaar uit de lucht vallen – er is een lange reeks voorwaarden die vervuld moeten zijn om dit te laten slagen. Deze omvatten:
- Een duidelijk begrip van en gevoel van verantwoordelijkheid voor het team’s doel en doelstellingen
- Team stabiliteit en onderlinge verbanden
- De overeenstemming binnen het team over taken en verantwoordelijkheden
- De Product Owner’s mandaat en discipline bij het verfijnen van de backlog
- Het vermogen van de Scrum Master om het team beschermen als gevolg van onvoorziene werkzaamheden
Zoals je ziet, zit er structuur en een proces achter het gebruik van relatieve schattingen, maar uiteindelijk komt het neer op de bedrijfscultuur. Relatieve schattingen werken alleen als je de onzekerheid bij complexe werkzaamheden accepteert en het team de ruimte geeft om zelf te beslissen hoe de klus geklaard moet worden. Als je de samenstelling van het team voortdurend verandert, zal dit nooit werken.
