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 doet 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 — en is de „betrokkenheid“ tegen woensdag stilletjes verdwenen.

Waarom, wat en hoe

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

• Waarom is deze sprint waardevol? Het antwoord ligt in het sprintdoel: één zin waar het hele team zich achter kan scharen. Zorg dat u hierover overeenstemming bereikt 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 van de bovenkant van de backlog die bijdragen aan het doel, totdat zij de grens 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, 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 om deze op te leveren.

Eerst de reikwijdte, daarna het plan

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

Deel één betreft de scope. De producteigenaar presenteert het doel en de kandidaat-items in volgorde van prioriteit. Het team stelt verduidelijkende vragen, toetst elk item aan de definitie van ‘klaar’ en neemt werk op totdat de capaciteit op is. Stop daar. De verleiding om „nog één“ klein verhaal erbij te proppen, is precies de reden waarom sprints te vol raken.

Deel twee is de planning. Nu gaat het team dieper in op de geselecteerde items — ze worden opgesplitst in taken, afhankelijkheden worden in kaart gebracht en er wordt afgesproken wie wat als eerste voor zijn rekening 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 bovenste items moeten al bekend zijn en er moet een ruwe inschatting van de omvang zijn gemaakt. Als het team een story pas tijdens de planning voor het eerst te zien krijgt, voert u backlogverfijning uit in de verkeerde vergadering — en dan zal deze uitlopen. 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 zij erbij zijn. Planning door tussenpersonen leidt tot toezeggingen waar niemand zich verantwoordelijk voor voelt.

Wie leidt het?

De Scrum Master treedt op als facilitator — hij waakt over de tijdlimiet, houdt de twee fasen gescheiden en voorkomt dat de vergadering ontaardt in het uitwerken van oplossingen voor elk randgeval. De productowner zorgt voor de doelstelling 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 er een in het hoofdstuk sprintplanning-agenda.

Waar het misgaat

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

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 geïnformeerd. Bij het plannen moet het gevoel heersen dat het team zelf kiest, en niet dat het iets toegewezen krijgt.

De overambitie. Capaciteit wordt behandeld als een ambitieus streefdoel. Het team neemt zijn hoogste ooit behaalde tempo als uitgangspunt en voegt daar nog 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 principe om te bepalen wat er moet 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 geef het team de verantwoordelijkheid voor de prognose. In de rest van deze handleiding wordt elk onderdeel uitgebreid behandeld — begin met de agenda of download het sjabloon voor sprintplanning.

Veelgestelde vragen

Wat is sprintplanning?

Sprintplanning is de Scrum-activiteit waarmee een sprint van start gaat. Het team komt een sprintdoel overeen, selecteert de backlog-items waarvan het verwacht dat deze kunnen worden afgerond, 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 week sprint — dus ruwweg twee uur voor een sprint van één week, vier uur voor een sprint van twee weken, tot 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, dan 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 beslissen zelf hoeveel werk zij op zich kunnen nemen en hoe zij dit zullen bouwen — het is aan hen om een prognose op te stellen, niet aan de productowner om deze toe te wijzen.