Sprint Planning Meeting: Definitie, verloop & belangrijke tips

De kick-off van elke Sprint is de Sprint Planning Meeting. Dit dient om de werklast van het Scrum-team voor de komende Sprint vast te stellen. Hoe de Sprint Planning Meeting door de Product Owner voorbereid moet worden, wie eraan deelneemt, hoe het verloop is en waar het team op moet letten, lees je in dit artikel.

Sprint Planning: doelen & deelnemers van de meeting

Een Sprint Planning Meeting heeft twee doelen. Na een geslaagde Sprint Planning:

• zijn de Product Owner en het Development Team het eens over het Sprintdoel (Outcome)
• en hebben ze gezamenlijk de Sprint Backlog samengesteld. De Sprint Backlog bevat alle Product Backlog Items die in de Sprint gerealiseerd moeten worden om het Sprintdoel te bereiken (Output).

Soms worden Outcome en Output ook samengevat als MVP, Minimum Viable Product.

Wie nodigt uit voor de Sprint Planning?

De Product Owner nodigt het ontwikkelteam en de Scrum Master uit voor de Scrum Planning Session. Als er daarnaast Stakeholders zijn die willen zien wat het Sprintdoel is en welke Backlog Items worden opgepakt, nodigt de Product Owner hen ook uit.

Voorbereiding van het Scrum Planning Meeting

Om ervoor te zorgen dat de Product Owner en het ontwikkelteam de twee doelen van het Planning Meeting bereiken, moet er aan een aantal voorwaarden worden voldaan. De volgende voorbereidende stappen zijn daarom essentieel vóór het Sprint Planning in Scrum. Als je zelf als PO werkt of je momenteel voorbereidt op de rol van Product Owner, kun je deze checklist gebruiken of de onderstaande punten als leidraad nemen.

• De Product Owner heeft een Sprintdoel (Outcome) gedefinieerd en de bijbehorende Product Backlog Items (PBI's) geselecteerd.
• De geselecteerde PBI's zijn voldoende gedetailleerd uitgewerkt – bij voorkeur in samenwerking met het ontwikkelteam, bijvoorbeeld tijdens een Product Backlog Refinement.
• De geselecteerde PBI's zijn in een volgorde gezet waarin het ontwikkelteam ze zal oppakken. Hierbij is rekening gehouden met technische afhankelijkheden.
• Het team beschikt over een Definition of Done (DoD). Deze zorgt voor een gedeeld begrip van „wanneer iets af is".
• De capaciteit van het team voor de volgende Sprint is bepaald, bijvoorbeeld op basis van de gemiddelde Velocity van de afgelopen Sprints en eventueel gepland verlof van individuele teamleden.

Het verloop van het Sprint Planning

Als het Sprint Planning zoals beschreven is voorbereid, kun je samen met je Scrum-team aan de slag met het eigenlijke verloop. Het meeting volgt de onderstaande Sprint Planning agenda:

• De Product Owner presenteert het Sprintdoel en de bijbehorende PBI's en beantwoordt vragen van het team. Het Sprintdoel moet voor alle teamleden goed leesbaar op het Sprint Backlog worden gedocumenteerd.
• Als de PBI's nog niet zijn ingeschat, is dit het moment om dat te doen. Heeft de inschatting al plaatsgevonden, dan kan je team na de gedetailleerde discussie over de uitvoering de inschatting nu verfijnen.
• Het team doet tegenover de Product Owner en stakeholders een voorspelling over welke PBI's het aan het einde van de Sprint conform de gezamenlijk opgestelde DoD zal opleveren. Op deze manier ontstaat het Sprint Backlog, waarin gedocumenteerd moet zijn aan welke PBI's het ontwikkelteam zich heeft gecommitteerd en welke het optioneel extra zal oppakken.

Uiteraard geldt er in Scrum ook voor het Sprint Planning een timebox: de duur van een Sprint Planning mag niet langer zijn dan één dag (Timebox: 8 Stunden).

Onderscheid tussen Sprint Planning 1 en 2

Onze praktijktip: Veel Scrum-teams maken onderscheid tussen Sprint Planning 1 en 2:

• Sprint Planning 1 richt zich op de vraag: Wat willen we in de komende Sprint aanpakken?
• Sprint Planning 2 behandelt de vraag: Hoe gaan we het aanpakken?

De timebox van beide Plannings wordt overigens niet gelijk verdeeld in elk 4 uur – in plaats daarvan is Planning 1 na een goed Refinement automatisch vrij kort, terwijl het grootste deel van de timebox nodig is voor Planning 2.

Hoewel dit niet verplicht is, breken sommige ontwikkelteams in Scrum Sprint Planning 2 de Product Backlog Items op in kleinere werkpakketten (Tasks). Dit tweede deel van het Sprint Planning vindt vaak plaats zonder de Product Owner.

Waar moet een team nog meer rekening mee houden bij de Sprintplanning?

Een ontwikkelteam zal tijdens een Sprint nooit uitsluitend aan de gekozen Sprint Backlog Items kunnen werken, want in elke agile werkomgeving zijn er tussendoor verstoringen, kleine noodgevallen en dringende supportvragen.

Daarom loont het voor je team om een soort buffer in de Sprints in te plannen, die bijvoorbeeld de volgende werkzaamheden meeneemt:

• Oplossen van operationele problemen, bijvoorbeeld als een server uitvalt
• Oplossen van kritieke bugs
• First- of second-level tech-support

Zulke buffers zorgen ervoor dat het Scrum Sprint Planning een Backlog oplevert die het team ook daadwerkelijk kan waarmaken, zonder gefrustreerd te raken door verstoringen. Bovendien laten onze onderzoeken zien dat teams met een buffer na verloop van tijd beter presteren. Dat komt onder andere doordat deze teams vaker hun Sprintdoelen halen en daardoor vaker succeservaringen hebben.

De resultaten van de Sprintplanning

Als jij en je team de volgende punten als afgerond kunnen markeren, weten jullie dat de Sprintplanning geslaagd is en jullie alles goed hebben gedaan:

• Het Scrum-team heeft een gedeeld begrip ontwikkeld van wat er in de komende Sprint bereikt moet worden (Sprintdoel).
• Door de onderlinge discussie van het ontwikkelteam hebben jullie een gedeeld begrip van hoe de betreffende PBI's uitgevoerd moeten worden.
• Jullie hebben een duidelijk Sprint Backlog opgesteld, dat de PBI's bevat in de volgorde van de Product Backlog, eventueel zelfs na een Task Breakdown inclusief bijbehorende taken.

De grootste fout bij het Sprint Planning Meeting

Sommige ontwikkelteams gaan er te krampachtig mee om het perfecte Sprint Backlog te creëren, door te proberen elke kleine taak te identificeren en uiterst nauwkeurig in te schatten. Dit gebeurt meestal wanneer het management de agile werkwijze nog niet volledig heeft begrepen en zulke "exacte" inschattingen eist.

Omdat bij een overdreven nauwkeurige schatting in het Sprint Planning Meeting te veel tijd verloren gaat, moet de Scrum Master ervoor zorgen dat het eigenlijke doel van de Planning niet uit het oog wordt verloren: namelijk de juiste PBI's voor de volgende Sprint selecteren en er net genoeg over te bespreken dat het team zich klaar voelt om de Items op te pakken.

Conclusie over het Sprint Planning Meeting

Een succesvol Sprint Planning Meeting staat of valt met een goede voorbereiding, zoals het Product Backlog Refinement. Het Sprint Planning Meeting levert op zijn beurt de voorwaarde dat iedereen in het team weet wat er in de volgende Sprint hoe uitgevoerd moet worden. Als de Sprint dus moet slagen en het ontwikkelteam de PBI's succesvol en zonder frustratie wil oppakken, is het Planning Meeting in Scrum absoluut onmisbaar.