De complete gids voor sprint planning

Sprint planning is een hoeksteen van Scrum die een Scrum team helpt zich voor te bereiden op hun komende sprint - het is de gebeurtenis die de sprint start. 

Maar wanneer moet je de sprint planning houden? Wat wordt er besproken? Wie is er aanwezig? In deze gids beantwoorden we al deze vragen en geven we tips om de sprint planning effectiever te maken.

Sprint planning is een van de vijf Scrum events waarin een Scrum team de prioriteiten voor de huidige sprint bespreekt en het sprintdoel definieert, oftewel wat het team tijdens de sprint wil bereiken. De meeting moet voldoende context bieden, zodat het team de sprint increment succesvol kan opleveren en aan het einde van de iteratie waarde kan leveren aan de stakeholders. 

Inzicht in sprint plans

Hoewel 'sprint plan' een veelgebruikte term is voor de uitkomst van een planningssessie, is het geen officiële agile term. Wat teams eigenlijk bouwen is de sprint backlog, wat een realtime plan is voor de iteratie. 

Het doel van dit proces is om een routekaart te creëren met zowel inputs als outputs voor de komende sprint. Inputs zijn de factoren die bepalen of het plan haalbaar is. Deze kunnen een geschiedenis omvatten van de snelheid van eerdere sprints en het aantal voltooide backlog items, schema's met betaald verlof van teams en meer. De outputs van sprint planning zijn het sprintdoel en de sprint backlog.

Teams die het Scrum framework niet gebruiken, kunnen een soortgelijke meeting houden genaamd iteratieplanning. De meeting deelt een vergelijkbaar doel: het team evalueert de prioriteit en haalbaarheid van aankomend werk en stelt een iteratiedoel.

De sprint planning wordt meestal op de eerste dag van de sprint gehouden, maar sommige teams doen dit graag de dag voordat de sprint begint.

De belangrijkste deelnemers aan de sprint planning zijn de product owner en de developers.

De product owner is verantwoordelijk voor het 'wat' en het 'waarom' van de sprint. Zij nemen als eerste het woord tijdens de meeting om de te verrichten werkzaamheden toe te lichten. Onthoud dat de product owner geen taken aan de sprint toevoegt; het team kiest taken op basis van wat haalbaar is.

De developers zijn verantwoordelijk voor het hoe en wanneer. Tijdens het tweede deel van de meeting beginnen ze vorm te geven aan het werk dat door de product owner wordt gepresenteerd. Ze doen dit door het werk dat nodig is verder uit te splitsen en de omvang, beschrijvingen en indelingen van backlog items te evalueren. Uiteindelijk vormen ze de sprint backlog, oftewel wat er uit de product backlog is gehaald, plus de details over hoe die items moeten worden afgerond. 

Je vraagt je misschien af wie de sprint planning leidt. Maar niemand 'leidt' de meeting. Integendeel, het team werkt samen, en de Scrum master faciliteert enigszins. Het is aan de Scrum master om evenwicht te brengen en het team eraan te herinneren wat realistisch is, vooral als de product owner te veel aandringt op wat er moet gebeuren of als de developers te veel tijd nodig hebben om iets gedaan te krijgen.

De Scrum Guide beveelt aan dat je voor een sprint van een maand maximaal acht uur hebt voor de sprint planning. Als je een sprint van twee weken doet, is vier uur het maximum voor de sprint planning. Met andere woorden, 'de algemene vuistregel is om twee uur sprint planning toe te staan voor elke week sprintlengte'. 

Naast de lengte van de sprint zijn er nog een paar andere factoren die kunnen bepalen hoe lang de sprint planning duurt. Hoe lang werkt het team bijvoorbeeld al aan het initiatief? Is het initiatief nieuw of bijna afgerond? Goede backlog refinement en facilitering leiden bovendien tot kortere meetings (drie uur of minder). 

Een sprint planning meeting die acht uur duurt, is vaak een teken dat er mogelijk onvoldoende voorbereiding is geweest.

Een sprint planning agenda omvat doorgaans een opening, een product backlog review, het sprintdoel, het aanmaken van een sprint backlog, een sprint backlog review en een afsluiting.

Opening

Aan het begin van de meeting kan de Scrum master een kort overzicht geven van het doel en de tijdsplanning van de meeting. 

Het team kan ook de capaciteit voor de komende sprint of iteratie bekijken, inclusief welke teamleden beschikbaar zijn, wat de werkdagen van het team zijn en meer.

Product backlog review

Vervolgens deelt de product owner de set geordende items uit de product backlog ter overweging. Dit is het moment waarop het team de reikwijdte en waarde, acceptatiecriteria en eventuele afhankelijkheden verduidelijkt. Een groot deel van deze discussie had al moeten plaatsvinden tijdens de backlog refinement, maar sindsdien kunnen er nieuwe items en informatie naar boven zijn gekomen. 

Sprintdoel

Tijdens deze fase van de meeting werkt het team samen om een doel op hoog niveau te definiëren voor de iteratie. In plaats van zich te richten op een bepaalde hoeveelheid taken, moet het team de specifieke waarde identificeren die het wil leveren aan stakeholders. 

Sprint backlog maken

Indien nodig selecteert het team de items uit de product backlog die het doel mogelijk maken en splitst ze op in kleinere werkitems om een plan te maken. Het team moet afhankelijkheden, risico's en mogelijke belemmeringen identificeren en plannen hoe het werk tijdens de iteratie zal worden uitgevoerd.

Sprint backlog review 

Op dit punt evalueert het team de sprint backlog en zorgt ervoor dat iedereen op één lijn zit. Dit is het moment om eventuele resterende hiaten, aandachtspunten of acties te identificeren. 

Afsluiting

Neem een paar minuten de tijd om de meeting goed af te sluiten. Het is niet ideaal om midden in een discussie abrupt te stoppen. Het team moet vertrouwen hebben in het sprint plan.

Ben je klaar om verder te gaan dan de basisprincipes van Agile sprint planning en te leren hoe je een overleg voor een sprint planning effectief kunt leiden? Ervaren Agile coaches Bryan Stallings en Jessica Guistolise delen enkele van hun beste tips voor effectieve sprint planning, vooral voor Scrum masters!  

Zorg dat je goed voorbereid bent met een verfijnde en geordende product backlog.

Het meenemen van een ongeordende, ongestructureerde product backlog naar de sprint planning leidt tot een lang overleg waarin je uiteindelijk de backlog moet verfijnen. Product owners moeten de komende anderhalve sprint (of anderhalve iteratie) verfijnen en ordenen vóór de sprint planning begint. Ga niet verder dan dat, anders vergeet het team de gesprekken over de items wanneer ze aan bod komen. Het is een goed idee om het volgende motto te hanteren: 'Net genoeg, net op tijd.'

Houd er rekening mee dat, zelfs als je met een verfijnde en geordende backlog komt, er tijdens een sprint review of retrospective nog iets nieuws naar voren kan komen dat aan de sprint moet worden toegevoegd. 

Geef het team voorafgaand aan de sprint planning toegang tot de product backlog.

Om stress te verminderen, kan het handig zijn om het team voorafgaand aan de sprint planning inzicht te geven in de product backlog. Als het team niet de kans krijgt om de backlog van tevoren te bekijken, kunnen teamleden verrast worden tijdens de sprint planning meeting, wat kan leiden tot risicomijdend gedrag en te hoge schattingen.

Overweeg het gebruik van een visueel canvas zoals Lucid om de product backlog te delen. Teamleden kunnen sticky notes, emoji reacties en meer toevoegen en de visual kan later worden gebruikt als een single source of truth.

Voorbeeld van een product backlog in Lucidspark. Maak je eigen kopie van deze sjabloon 

Stel realistische verwachtingen op met de product owner

Een veelgemaakte fout van product owners is dat ze hetzelfde aantal items van de vorige sprint meenemen naar de huidige sprint. Ze zouden anderhalve iteratie aan items mee moeten nemen naar de meeting. Op deze manier zijn er genoeg items om door te praten en mee te nemen naar de sprint, voor het geval er open vragen zijn waardoor het team die sprint niet aan specifieke items kan werken. Of, als de items in de sprint naar schatting minder tijd in beslag zullen nemen, heeft de product owner wat extra backlog items klaarliggen.

Houd rekening met activiteiten buiten het ontwikkelen om.

Vergeet niet om ook tijd vrij te maken voor activiteiten die niet direct met ontwikkelen te maken hebben, zoals meetings, trainingen en andere organisatorische taken. Door deze activiteiten toe te voegen, kan het team een realistischer plan opstellen en overbelasting voorkomen.

Laat het team de sprint backlog beheren.

De Scrum master hoort geen taken en backlog items toe te wijzen. In plaats daarvan moeten teamleden de sprint backlog bekijken en het volgende overwegen:

• Is er een vaardigheid die ik wil ontwikkelen?

• Is er iemand die hier heel goed in is?

• Hoe willen we dit gezamenlijk aanpakken? 

Stimuleer realistische toezeggingen.

Teams doen vaak te veel toezeggingen als ze nieuw zijn met sprint planning, omdat er een neiging om te willen behagen of een gebrek aan bewustzijn van afhankelijkheden buiten het team kan zijn. Hoewel enthousiasme wordt gewaardeerd, kan te veel optimisme over wat er in één sprint kan worden bereikt schadelijk zijn voor het team. Het is moeilijker om aan het eind van een sprint verschillende items naar achteren te schuiven dan om tijdens de sprint nieuwe items toe te voegen als het team capaciteit heeft. 

Om te veel toezeggingen te voorkomen, is het belangrijk om te denken aan Agile teamcapaciteitsplanning. De Scrum master kan een reality check uitvoeren door te verwijzen naar sprints uit het verleden en het team te vragen om 'inspectie en aanpassing'. In wezen betekent dit dat je het team vraagt om kritisch te kijken naar wat ze kunnen bereiken en het sprintdoel en de backlog daarop aan te passen. 

Creëer veiligheid en vertrouwen in de meeting.

Scrum masters moeten helpen een sfeer van transparantie en open communicatie te creëren voor de meeting. Niemand moet zich ongemakkelijk voelen om zorgen te uiten over de capaciteit, vragen te stellen of misverstanden op te helderen.

Backlog refinement is doorgaans de verantwoordelijkheid van de product owner. Dit houdt in dat diegene op de hoogte is van toekomstig werk en antwoorden verzamelt op vragen over de items in de product backlog voordat deze tijdens de sprint planning meeting worden besproken. 

Hoewel in de Scrum Guide geen sprake is van een backlog refinement meeting, is die wel gebruikelijk bij Scrum teams. Andere teams verfijnen de backlog asynchroon.

Waar sprint planning bedoeld is om een plan te maken voor bijvoorbeeld de komende twee weken, is een program increment (ook wel PI planning of big room planning genoemd) een planningssessie op hoog niveau die de komende maanden voor een team moet sturen. Sprint planning is een meer gedetailleerde analyse van hoe het PI-plan sprint voor sprint kan worden gerealiseerd.  

PI planning is geen vereiste uit de Scrum Guide, maar het is een goede werkwijze voor teams en wordt vaak gebruikt wanneer veel teams aan iets complex werken. Kleinere organisaties met slechts één of twee Scrum teams hebben geen PI planning nodig.

Bespaar tijd en maak consistente, boeiende sprint planning meetings mogelijk met de volgende sjablonen van Lucid, software voor sprint planning.

Gedetailleerd sjabloon voor sprint planning

Dit sjabloon helpt teams op weg en begeleidt ze door elke stap van de sprint planning. Met functies zoals hulpmiddelen, Lucid kaarten en visuele activiteiten die direct in het sjabloon zijn ingebouwd, kun je ervoor zorgen dat je team gefocust blijft, het werk wordt overgedragen naar je project management tool, en je begrijpt hoe het team denkt over het voorgestelde sprint plan.

Klik op de afbeelding om dit sjabloon te gebruiken.

Eenvoudig sjabloon voor sprint planning

Wil je een meer rechttoe rechtaan benadering? Dit sjabloon bevat de basisstappen die teams nodig hebben om een aankomende sprint te plannen.

Klik op de afbeelding om dit sjabloon te gebruiken.

Sjabloon en teamruimte voor sprint planning meeting

Dit sjabloon bootst de bruikbaarheid van een echte teamruimte na om het gevoel van samenhorigheid en samenwerking binnen je team te vergroten.

Klik op de afbeelding om dit sjabloon te gebruiken.

Lucid kan je helpen om niet alleen je volgende sprint planning meeting naar een hoger niveau te tillen, maar ook al je Agile evenementen! Met functies die zijn ontwikkeld voor facilitering en samenwerking, een oneindig canvas, kant-en-klare sjablonen en meer maakt Lucid Agile samenwerking een fluitje van een cent voor teams – hybride, op afstand of op kantoor.