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, waarna de „toewijding“ tegen woensdag stilletjes in duigen valt.

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 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 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 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 om deze op te leveren.

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 omvang. 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 is uitgeput. 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, splitst deze op in taken, brengt afhankelijkheden in kaart en komt overeen wie wat als eerste op zich neemt. Dit is het moment waarop u het verhaal ontdekt dat op een 3 leek, maar in werkelijkheid een week werk verbergt achter een vaag acceptatiecriterium.

Door deze twee zaken gescheiden te houden, voorkomt u dat er bij elk afzonderlijk punt een discussie ontstaat tussen „moeten we dit aannemen?” en „hoe zouden we dit moeten opzetten?”.

Wat u in de kamer nodig hebt

Sprintplanning werkt alleen als de input al klaar is. Tijdens de vergadering wordt de input omgezet in een plan; deze wordt niet ter plekke bedacht.

• Een verfijnde, geprioriteerde backlog. De belangrijkste items moeten al bekend zijn en er moet een ruwe schatting van de omvang zijn gemaakt. Als het team een story pas tijdens de planningsvergadering voor het eerst ziet, voert u backlogverfijning uit in de verkeerde vergadering, 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 snelheid en capaciteitsplanning.
• Het hele team. De ontwikkelaars stellen de prognose op, dus zij moeten daarbij aanwezig zijn. Planning door tussenpersonen leidt tot toezeggingen waar niemand zich verantwoordelijk voor voelt.

Wie leidt de organisatie?

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 bepalen zelf hoeveel werk zij op zich nemen en hoe zij dit zullen realiseren.

Dat laatste punt is van belang: de prognose is eigendom 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. Zorg ervoor dat de input klopt, dan wordt de vergadering vanzelf korter. Als u een minutieus tijdschema wenst, vindt u een voorbeeld daarvan in het hoofdstuk agenda voor sprintplanning.

Waar het misgaat

Drie soorten mislukkingen liggen ten grondslag aan de meeste slecht verlopende planningsvergaderingen.

De leessessie. De producteigenaar 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 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. Vervolgens zorgen een storing in de ondersteuning, een ziektedag en één onderschatte feature ervoor dat de sprint verandert in een hectische situatie. Plan op basis van een bescheiden schatting, niet op basis van een heroïsche.

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 een nette staat wordt opgeleverd. Het doel is wat u aangeeft welke tickets u onder druk moet laten vallen.

Zorg dat de input klaar is, houd de reikwijdte 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 gebruik het sjabloon voor 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 dient de sprintplanning te duren?

Stel de tijdslimiet vast op ongeveer twee uur per week per sprint, 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. Dit 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 belangrijkste 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 opbouwen: het is aan hen om een prognose op te stellen, en niet aan de productowner om taken toe te wijzen.