De sprintplanningsvergadering, stap voor stap

Sprintplanning is de vergadering waarmee een sprint van start gaat. Tijdens deze vergadering komt het team een sprintdoel overeen en beslist het hoeveel van de backlog het realistisch gezien kan afronden, waarbij een geprioriteerde lijst wordt omgezet in een plan waarin het team daadwerkelijk gelooft. Een backlog is een verlanglijstje totdat iemand beslist wat er vervolgens wordt gebouwd. Die beslissing wordt genomen tijdens de sprintplanning.

Als het goed wordt aangepakt, duurt het een uur of twee en vertrekt het team met het besef wat het moet doen en waarom. Als het slecht wordt aangepakt, verwordt het tot een sessie waarin de backlog wordt doorgenomen, waarbij de productowner tickets toewijst en iedereen instemmend knikt, waarna de „betrokkenheid“ tegen woensdag stilletjes in duigen valt.

Waarom, wat en hoe

De Scrum Guide structureert de sprintplanning rond drie vragen, en het is raadzaam deze in deze volgorde te handhaven:

• Waarom is deze sprint waardevol? Het antwoord ligt in het sprintdoel: één zin waar het hele team zich achter kan scharen. Zorg dat u het hierover eens bent voordat u aan de backlog begint. Het vaststellen van een sprintdoel is een vaardigheid op zich.
• Wat kan er deze sprint worden gedaan? De ontwikkelaars halen taken uit de bovenste laag van de backlog die bijdragen aan het doel, totdat zij de grenzen van hun capaciteit bereiken. Dit is een prognose, geen belofte die onder ede is afgelegd.
• Hoe zal het geselecteerde werk worden uitgevoerd? Het team werkt de belangrijkste punten uit tot een plan dat voldoende gedetailleerd is om aan de slag te gaan: taken, een aanpak en de voor de hand liggende risico’s. Niet elk punt tot in de kleinste subtaak, maar wel voldoende om met vertrouwen van start te gaan.

Het resultaat is een sprintbacklog: het doel, de geselecteerde items en het plan voor de oplevering daarvan.

Eerst de reikwijdte, daarna het plan

De allerbelangrijkste structurele gewoonte is om de planning in twee afzonderlijke fasen uit te voeren in plaats van in één onduidelijke fase.

Deel één betreft de reikwijdte. De producteigenaar presenteert het doel en de kandidaat-items in volgorde van prioriteit. Het team stelt verduidelijkende vragen, toetst elk item aan de hand van de definitie van ‘gereed’ en neemt werk op totdat de capaciteit op is. Stop daar. De verleiding om er ‘nog één’ klein verhaal tussendoor te proppen, is precies de reden waarom sprints te veel hooi op hun vork nemen.

Deel twee is de planning. Nu gaat het team dieper in op de geselecteerde items, splitst deze op in taken, brengt afhankelijkheden in kaart en spreekt af wie wat als eerste op zich neemt. Hier ontdekt u dat het verhaal dat op een 3 leek, in werkelijkheid een week werk verbergt achter een vaag acceptatiecriterium.

Door deze twee zaken gescheiden te houden, voorkomt u dat de vergadering bij elk afzonderlijk punt heen en weer slingert tussen „moeten we dit aannemen?” en „hoe zouden we dit opzetten?”.

Wat u in de kamer nodig hebt

Sprintplanning werkt alleen als de benodigde gegevens al klaar zijn. Tijdens de vergadering worden deze gegevens omgezet in een plan; ze worden niet ter plekke bedacht.

• Een verfijnde, geprioriteerde backlog. De belangrijkste items moeten al bekend zijn en er moet een ruwe inschatting van de omvang zijn gemaakt. Als het team tijdens de planningsbijeenkomst voor het eerst kennismaakt met een story, voert u de verfijning van de backlog in de verkeerde vergadering uit, en zal deze te lang duren. Verfijning is de voorbereiding; planning is de besluitvorming.
• Een reëel capaciteitscijfer. Niet „twee weken maal de teamgrootte”, maar het aantal uren dat daadwerkelijk beschikbaar is na aftrek van verlof, vergaderingen, ondersteuningsdiensten en de „onderbrekingslast”. Zie „velocity” en „capaciteitsplanning”.
• Het hele team. De ontwikkelaars stellen de prognose op, dus moeten de ontwikkelaars daarbij aanwezig zijn. Planning door tussenpersonen leidt tot toezeggingen waar niemand zich verantwoordelijk voor voelt.

Wie leidt het?

De Scrum Master fungeert als facilitator: hij bewaakt de tijdslimiet, houdt de twee fasen gescheiden en voorkomt dat de vergadering ontaardt in het uitwerken van oplossingen voor alle randgevallen. De productowner zorgt voor het doel en de geordende backlog, en beantwoordt ter plekke de „waarom“- en „wat“-vragen. De ontwikkelaars beslissen hoeveel werk zij op zich nemen en hoe zij dit zullen bouwen.

Dat laatste punt is van belang: de prognose is van degenen die het werk uitvoeren. Een plan dat van bovenaf wordt opgelegd en zwijgend wordt aanvaard, is geen verbintenis. Het is een wachtrij.

Hoe lang dit zou moeten duren

De Scrum Guide voorziet in een planning van maximaal acht uur voor een sprint van één maand, en proportioneel minder voor kortere sprints, dus ongeveer twee uur per sprintweek. Een sprint van twee weken zou ongeveer vier uur in beslag moeten nemen, vaak minder zodra een team een vast ritme heeft gevonden.

Beschouw dat als een maximum, niet als een streefdoel. Teams die steevast de volledige tijdslimiet nodig hebben, zijn vrijwel altijd bezig met verfijning tijdens de planning. Breng de input op orde, en de vergadering wordt vanzelf korter. Als u een minutieus tijdschema wenst, vindt u dat in het hoofdstuk over de agenda voor de sprintplanning.

Waar het misgaat

De meeste slecht verlopende planningsvergaderingen zijn te wijten aan drie soorten mislukkingen.

De leessessie. De productowner neemt de tickets door en het team luistert. Er worden geen beslissingen genomen, omdat niemand de beslissingen neemt; het team wordt alleen ingelicht. Bij het plannen moet het gevoel heersen dat het team zelf kiest, en niet dat het iets toegewezen krijgt.

De overambitie. Capaciteit wordt beschouwd als een ambitieus streefdoel. Het team neemt zijn hoogste ooit behaalde doorvoersnelheid als uitgangspunt en voegt daar een beetje aan toe uit ambitie. Maar dan zorgen een storing in de ondersteuning, een ziektedag en één onderschat verhaal ervoor dat de sprint verandert in een chaos. Plan op basis van een bescheiden cijfer, niet op basis van een heroïsch cijfer.

Plannen zonder doel. Het team selecteert een bonte verzameling onderling niet-gerelateerde tickets, en wanneer de sprint krap wordt, ontbreekt het aan een duidelijk uitgangspunt om te bepalen welke tickets moeten worden geschrapt, waardoor alles een beetje uitloopt en er niets in zijn geheel wordt opgeleverd. Het doel is wat u aangeeft welke tickets u onder druk moet laten vallen.

Zorg dat de input klaar is, houd de scope en het plan gescheiden en laat het team zelf de verantwoordelijkheid nemen voor de prognose. In de rest van deze handleiding wordt elk onderdeel uitgebreid behandeld. Begin met de agenda of download het sjabloon voor de sprintplanning.

Veelgestelde vragen

Wat is sprintplanning?

Sprintplanning is de Scrum-bijeenkomst waarmee een sprint van start gaat. Het team komt een sprintdoel overeen, selecteert de backlog-items waarvan het verwacht dat deze kunnen worden voltooid, en schetst hoe het werk zal worden uitgevoerd. Hierbij worden drie vragen beantwoord: waarom de sprint waardevol is, wat er zal worden gebouwd en hoe.

Hoe lang moet de sprintplanning duren?

Stel de tijdslimiet vast op ongeveer twee uur per sprintweek, dus ruwweg twee uur voor een sprint van één week, vier uur voor een sprint van twee weken en maximaal acht uur voor een maand. Dat is een maximum, geen streefcijfer. Als u consequent de volledige tijdslimiet nodig hebt, was de backlog bij aanvang meestal nog niet klaar.

Wat zijn de belangrijkste stappen bij de planning voor de sprint?

Stel de werkelijke capaciteit van het team voor de sprint vast; spreek een sprintdoel af; selecteer backlog-items die aan dat doel bijdragen totdat de capaciteit is bereikt; verdeel de bovenste items in een uitvoerbaar plan; en zorg ervoor dat het team achter de prognose staat. Eerst de omvang bepalen, daarna het plan opstellen – in die volgorde.

Wie leidt de sprintplanning?

De Scrum Master begeleidt het proces en zorgt ervoor dat het binnen de vastgestelde tijdslimiet blijft. De productowner zorgt voor een geprioriteerde, verfijnde backlog en legt uit waarom bepaalde taken prioriteit hebben. De ontwikkelaars bepalen zelf hoeveel werk zij op zich kunnen nemen en hoe zij dit zullen realiseren: het is aan hen om een prognose op te stellen, niet aan de productowner om deze toe te wijzen.