We hebben een basis: de Product Backlog. We weten dat deze is geprioriteerd door de Product Owner. Met behulp van deze informatie beslissen we tijdens de Sprint Planning Meeting wat de aankomende sprint wordt uitgevoerd.
Evenals de sprint is ook de Sprint Planning Meeting timeboxed. De meeting duurt – afhankelijk van de grootte van de sprint – maximaal acht uur. De Scrum Master houdt de tijd in de gaten en is ervoor verantwoordelijk dat de meeting daadwerkelijk plaatsvindt. Naast het monitoren van de tijd leert de Scrum Master het Development Team hoe je een Sprint Planning binnen de timebox kan afronden. Ook zorgt de Scrum Master ervoor dat voor iedereen het doel van de Scrum Planning Meeting duidelijk is.
Het volledige scrumteam komt dus bijeen. En dan? Wanneer het doel is bepaald wordt gekeken welke middelen nodig zijn om dit daadwerkelijk te behalen. Er wordt ook een inschatting gemaakt van de tijd die nodig is voor verschillende items uit de sprint. Het Development Team beoordeelt zelf hoeveel taken kunnen worden uitgevoerd binnen deze termijn. Hierbij hoeft de Product Owner niet aanwezig te zijn. Deze inschatting wordt onder andere gemaakt op basis van capaciteit gedurende de sprint en prestaties uit het verleden.
Een hulpmiddel is Sprint Planning Poker. Gaan we nu ineens kaarten in plaats van werken? Nee, de cijfers op de kaarten dienen om een waarde toe te kennen aan de complexiteit van een taak. We splitsen de sprint dus op in losse taken en per taak (User Story) wordt door ieder teamlid een inschatting gegeven van de complexiteit ten opzichte van voorafgaande taken. De personen met de hoogste en laagste inschatting lichten hun keuze toe. Het spel wordt net zolang gespeeld tot overeenstemming wordt bereikt. Als team kan je beter iets te hoog inzetten, wat inhoudt dat je jezelf wat meer tijd geeft voor een User Story. Zijn al je taken afgerond voor het einde van de sprint? Dan voeg je in overleg nieuwe User Stories toe.
Om de Sprint Planning concreet te maken wordt een Sprint Backlog gevuld. Aan de hand hiervan verantwoordt het Development Team hoe het sprintdoel gehaald wordt. Deze backlog bevat een plan van aanpak en de items die geselecteerd zijn uit de Product Backlog. Niet de hele sprint hoeft hierin nauwkeurig te zijn verwerkt. Het werk dat gedaan wordt gedurende de eerste dagen van de sprint is voldoende. Voor de uitvoering van de werkzaamheden is het Development Team zelf verantwoordelijk.
Hopelijk is het doel van de Sprint Planning Meeting een beetje duidelijk geworden. Waarschijnlijk roepen bepaalde termen nog wat vragen op. Er wordt gesproken over User Stories, taken en items. Wat houden ze precies in? Volgende week worden ze uitgebreid toegelicht in het artikel over de Sprint Backlog.
