De Sprint Planning is één van de vijf events binnen het Scrum Framework. Alle events zijn: 1. De Sprint, 2. Sprint Planning , 3.Daily Scrum, 4. Sprint Review 5. Spint Retrospective.
De Sprint Planning vindt plaats aan het begin van elke Sprint. In de laatste versie van de Scrum Guide, Scrum Guide 2020, staat over de lengte van de Sprint Planning dat deze maximaal 8 uur duurt bij een Sprint van 4 weken. Werk je met Sprints van 2 of 3 weken? Dan duurt je Sprint Planning waarschijnlijk korter—hoewel veel zal afhangen van de complexiteit van het onderwerp en hoe goed het team inmiddels is ingewerkt met elkaar.
Het doel van de Sprint Planning is om te bepalen wat er de komende sprint aan werk opgepakt kan worden om de meeste waarde te leveren aan de klant. De Product Owner geeft aan waarom deze sprint waardevol is voor de klant en hoe deze zich verhoudt tot het Product Goal, het commitment wat ligt op de Product Backlog.
Samen met het gehele Scrumteam wordt vervolgens een Sprintdoel geformuleerd om deze klantwaarde te realiseren. Op basis hiervan maken de Developers een selectie van de Product Backlog Items, schatten in hoe groot deze zijn en formuleren taken voor de eerste dagen in de sprint. De lijst met het op te pakken werk is het fysieke eindresultaat van de Sprint Planning. Vanaf hier ligt de focus van de sprint op het realiseren van de Sprint Backlog.
De Scrum Master draagt er zorg voor dat de meeting plaatsvindt en dat zowel de Product Owner als de Developers weten waarom deze meeting plaatsvindt. Indien nodig faciliteert de Scrum Master ook. Het zorgdragen dat de meeting plaatsvindt moet niet verward worden met het inplannen van de meeting, reserveren van een ruimte en faciliteren met gebak en koffie. Dit is expliciet niet de verantwoordelijkheid van de Scrum Master.
De Product Owner zorgt dat er een werkbare Product Backlog is met een Product Goal. Vrij vertaald staat hierop wat de klant graag wil en waarom. Praktisch gezien is het een lijst met de eisen van de klant tav het eindproduct. Bovenaan de Product Backlog zouden er dan in ieder geval redelijk sprintklare versies van PBI’s moeten staan, liefst al gerefined door het team. De Product Owner moet helder hebben wat de waarde is die de komende sprint gaat vertegenwoordigen.
Op basis van het ‘waarom’ van deze sprint wordt door het gehele team een Sprintdoel gesteld. Dit is belangrijk om te hebben; dit is het commitment wat vastligt op de Sprint Backlog. Het Sprintdoel is een soort “heilige grond”—hier gaat het team voor, hierop ligt de focus van het werk wat we zullen doen de komende Sprint. Het Increment wat geleverd wordt aan het einde van de Sprint is het opgeleverde Sprintdoel. Daarom is het ook belangrijk om de Definition of Done ook meteen hier al duidelijk te hebben; aan welke kwaliteit moet het Increment voldoen om zoveel mogelijk waarde te kunnen leveren.
Nu het sprintdoel duidelijk is, wordt het tijd om de meest waardevolle PBI’s vop de Product Backlog in te schatten op grootte en te selecteren. Vaak kunnen niet alle PBI’s mee—de Developers kunnen met hun kennis en kunde goed inschatten welke welke PBI’s of User Stories zij de sprint in kunnen meenemen om het Sprintdoel te kunnen halen. Ze houden hierbij o.a. rekening met beschikbare tijd van de teamleden, kennis, complexiteit en haalbaarheid; gouden randjes worden er zoveel mogelijk afgeknipt om te komen tot een MVP, een Minimum Viable Product. We willen immers niet meer doen dan nodig om tijdens de Review feedback op te halen op het opgeleverde deeldoel, het increment, om zo verder te komen in de richting van het einddoel.
Zoals gezegd moet er in ieder geval ingeschat zijn wat de hoeveelheid moeite, “Effort” is die in iedere PBI gaat zitten. Planning Poker is hiervoor een handige tool. Het lijkt inderdaad op een kaartspel, hoewel er ook apps zijn waarmee je hetzelfde kunt doen. Op de kaarten staan getallen uit de Fibonacci reeks; het dubbele aantal punten of de helft groter inschatten gaat hiermee niet—en hiermee wordt de discussie al aangewakkerd.
Verder gaat het bij Planning Poker om relatief inschatten; je schat altijd de effort van een PBI in t.o.v. iets uit het verleden. Deze werkwijze heeft veel voordelen: er wordt veel kennis tussen de teamleden gedeeld op deze wijze. Ok wordt de voorspelbaarheid van wat een team kan leveren in een sprint op deze wijze steeds groter. En last but not least: het team leert elkaar steeds beter kennen en het vertrouwen wat noodzakelijk is om goed te kunnen werken in een zelforganiserend Scrumteam wordt zo ook bevorderd. Maar let op: hoe handig de tool ook is, er is geen verplichting om deze te gebruiken binnen scrum; in de Scrum Guide 2020 zul je niets over dit hulpmiddel vinden.
Indien de User Stories nog niet gedetailleerd genoeg zijn, kunnen de Product Backlog Items tijdens de Sprint Planning verder uitgekristalliseerd worden samen met de Product Owner, die hierbij vragen kan beantwoorden. Dit noemen we de Refinement. Hiernaar wordt soms wel eens gerefereerd als een extra optioneel event. Echter, Refinement gebeurt continu en niet alleen tijdens de Sprint Planning. Het is de verantwoordelijkheid van de Product Owner dat de Refinement gebeurt en zo’n 10% van de totale tijd van een Sprint gaat hierin zitten.
Als de PBI’s ingeschat zijn, en meegenomen naar de Sprint Backlog, dan wordt het ook tijd om in elk geval voor de eerste dagen van de sprint taken op de Sprint Backlog te zetten. Waarom niet voor de hele Sprint? We werken Empirisch, en ook tijdens de Sprint leren we steeds; de Sprint Backlog kan daarom op taakniveau ook tijdens de Sprint nog veranderen. Wat belangrijk is dat we het commitment op de geselecteerde PBI’s en het Sprintdoel als team geven als laatste actie in de Sprint Planning en dat wat we doen steeds transparant is voor het hele team.
Aan het begin van de Sprint Planning hebben we als Scrum team een sprintdoel bepaald. Dit vat samen wat waarde heeft voor de klant en op de Sprint Backlog staat verder hoe de Developers deze waarde gaan realiseren.
Dit is weerspiegeld door een Sprint Backlog waar het commitment, Het Sprintdoel op staat, met alle voor deze sprint geselecteerde relevante PBI’s of User Stories. De Developers zetten hier verder nog taken en sub-taken bij. Deze PBI’s of User Stories zijn tijdens de planning of al daarvoor tijdens de Refinement voorzien van een inschatting van effort om gemakkelijker te bepalen hoeveel werk meegenomen kan worden in de Sprint. Van Product Backlog tot Sprint Backlog blijft het werk wat al verzet is, en ook wat nog gedaan moet worden transparant voor het hele team; zo kunnen we voortdurend leren en verbeteren om de meeste waarde te kunnen leveren aan de stakeholders.
Loopt je Sprint niet lekker en weet je niet waar het aan ligt? Heb je moeite om met een goed Sprintdoel te komen? Misschien lukt het telkens niet om je Sprintdoel te realiseren. Neem contact op met één van onze collega’s, we kijken en denken graag met je mee.