Wat is de Sprint Planning
De Sprint Planning is één van de 5 Scrum Events en luidt de start van de nieuwe Sprint in. Tijdens de Sprint Planning bepaalt het Scrum Team het Sprint Doel op basis van wat de Product Owner als meest waardevolle werk beschouwd. Tevens geven de Developers aan wat voor hun belangrijk is om op te nemen, bv feedback uit de Retrospectives, wegwerken van technical debt, … .
Het commitment van het Scrum Team op het einde van de Sprint Planning is het Sprint Doel (Sprint Goal). Dit is de X op de map.
De weg naar de X wordt bepaald door wat we weten (empirisme) en is, met wat we op dit moment weten, de meest logische route er naar toe. Tijdens de Sprint doen we nieuwe kennis op, waardoor we mogelijks ons sprint plan moeten bijstellen. We houden wel het bereiken van de X als doel!
Het Sprint Doel is namelijk de Waarde (Value) die we willen realiseren. De weg er naar toe (de planning) is slechts een hulpmiddel om deze te behalen.
Het Sprint Doel wordt opgesteld tijdens de Sprint Planning en daarna toegevoegd aan de Sprint Backlog. Tijdens het werken in de Sprint houden de Developers het Sprint Doel voor ogen. Indien het werk anders blijkt te zijn dan de Developers hadden verwacht, werken zij binnen de Sprint samen met de Product Owner om over de scope van de Sprint Backlog te onderhandelen, zonder daarbij het Sprint Doel aan te tasten.
Het Sprint Doel is heilig. De aanpak die tijdens de Sprint Planning wordt uitgestippeld, is de route waarvan het Scrum Team gelooft dat deze de beste weg is om het Sprint Doel te halen. Tijdens de Sprint leren we bij en zullen we onverwachte zaken tegen komen waardoor onze uitgestippelde route (oplossing) zal moeten aangepast worden.
Oplossingen waarvan we overtuigd waren dat ze zouden werken, blijken toch niet voldoende. Of een andere software component dan we eerst gingen gebruiken blijkt alsnog een betere fit, … Zaken die kunnen en zullen gebeuren.
Helemaal ok! Het commitment is het halen van het Sprint Doel, niet de initieel gekozen oplossing !
Naar mate het team meer vertrouwd geraakt met zowel het Product alsook met de interne samenwerking zal de aanpak die tijdens de Sprint Planning bepaald is, ook vaker realiteit worden. Het blijft belangrijk om het halen van het Sprint Doel te meten als commitment en niet de planning op zich!
Als Scrum Master begeleid je de Developers, de Product Owner en de organisatie in wat de doelstelling van de Sprint Planning is, en vooral welk commitment er uit voort komt. Dit juist stellen is één van de sleutel momenten naar Agile denken: niet de planning nastreven, wel de Waarde (Value).
Hoe de Sprint Planning organiseren?
- De Scrum Master plant de Sprint Planning events repetitief in, 1 per Sprint, aan het begin van de Sprint, zelfde dag, zelfde tijdsslot.
- De Scrum Master begeleidt de Developers en de Product Owner tijdens de Sprint Planning tot het beschrijven van het Sprint Doel.
Wat is de structuur van het Sprint Planning event?
.In onze training Hoe zorg je voor positieve en productieve Scrum Events, hebben we het gehad over divergerend en convergerend denken
Stap1: Waarom is deze Sprint waardevol.
De Product Owner legt uit wat deze Sprint waardevol zal maken. Dit is gebaseerd op de Product Backlog Items (PBIs) bovenaan de Product Backlog. Idealiter zijn deze PBIs reeds op de Backlog Refinement door het team besproken en gedetailleerd geweest, wat de productiviteit tijdens de Sprint Planning ten goede komt, maar het is geen must! Is er iets nieuws op de backlog gekomen, pas dan de techniek uit de Product Backlog Refinement toe op dit item.
Begrijpt het Scrum Team wat de Sprint waardevol zal maken? Stel dan een draft Sprint Doel op. Dit Sprint Doel is het onderwerp dat ons doorheen de Sprint Planning zal leiden. Schrijf dit draft Sprint Doel op een postit en maak het voor iedereen zichtbaar.
De enige reden om een Sprint te annuleren is wanneer het Sprint Doel geen waarde meer zou leveren.
Enkel de Product Owner mag deze beslissing nemen.
Stap2: Gather Data
Gather Constraints
In deze stap willen we kennis uit de groep halen om te ontdekken met wat we tijdens de Sprint moeten rekening houden. Is er iemand met verlof, is er een systeem upgrade gepland of een onbeschikbaarheid, geeft de Product Owner een training, .. allemaal nuttige informatie die ons zal helpen besluiten hoeveel werk we in deze Sprint aan kunnen. Laat het Scrum Team eerst individueel nadenken over mogelijke ‘constraints, belemmeringen’ om het daarna in groep te bespreken.
Door eerst ieder de constraints waar die aan denkt te laten neerschrijven vergroot je de kans op volledigheid. Maak je hier direct een groepsgebeuren van, dan krijg je waarschijnlijk confirmation bias, waarbij de deelnemers eerder gaan doordenken op wat er gezegd is dan op zoek te gaan naar nieuwe ideeën en informatie.
Gather (Share) Velocity.
Velocity geeft aan wat een team in een bepaalde grootteorde (Storypoints, T-shirts sizes, appelen en bananen, ..) aan werk verzet zou kunnen krijgen in een Sprint. Dit cijfer is gebaseerd op kennis uit eerdere sprints. Maak dit cijfer zichtbaar voor de deelnemers.
Gather (Share) Data – Definition of Done.
De Definition of Done is het kwaliteitslabel dat de Developers nastreven voor het Increment. Maak deze zichtbaar. Door de Definition of Done zichtbaar te maken, wordt het gebruikt en bijgevolg toegepast.
Stap3: Bepaal de WAT wordt opgenomen in de Sprint
Door combinatie van de zaken uit de vorige 2 stappen: Het draft Sprint doel en de constraints, velocity, Definition of Done; kunnen de Developers bepalen welke Product Backlog Items toepasbaar zijn en haalbaar in de Sprint.
Hieruit krijgen we een spanningsveld tussen wat volgens de Developers haalbaar is en wat voor de Product Owner gewenst is.
Met het Draft Sprint doel in gedachten is het aan de Developers samen met de Product Owner om te besluiten welke PBIs in de Sprint opgenomen worden. Mogelijks worden PBIs verder opgesplitst om enkel datgene wat bijdraagt aan het Sprint Doel op te nemen.
Finaal is het aan de Developers (en enkel aan de Developers) om aan te geven wat hun haalbaar lijkt. Deze geselecteerde Product Backlog Items wordt de Sprint Backlog.
Stap4: Bepaal de HOE de Sprint Backlog gerealiseerd zal worden
Kiezen de Developers voor XP (eXtreme Programming), TDD (Test Driven Development), BDD (Behaviour Driven Development), Pair Programming of nog een andere aanpak .. hun keuze!
Herinner de Developers er wel aan dat ze als Team verantwoordelijk zijn voor het halen van het Sprint Doel en dat we vanuit Scrum voor samenwerking gaan ipv ieder hun eigen backlog item welke op het einde van de Sprint worden samengevoegd. (hebben we al zien gebeuren
).
De output van deze stap is een planning. Ja hoor, ook in Scrum doel we planning! ( It’s kind of in the name of this event 🤯). Idealieter mappen de Developers het werk op de beschikbare dagen in de Sprint en benoemen ze hoe ze als team de PBIs zullen realiseren. Deze planning, samen met het Sprint Doel, zijn het onderwerp om tijdens de Daily Scrum te inspecteren qua vooruitgang van de Sprint richting het Sprint Doel.
Stap5: Bevestig het Sprint Doel
Is het Sprint Doel bevestigd, dan eindigt de Sprint Planning en gaat de nieuwe Sprint van start.
Heel belangrijk : Ook al is het Sprint Doel de drijfveer, de Why van van de Sprint, daarom hoeven niet alle gekozen PBIs van Sprint Backlog hieraan te voldoen. Denkt het team op een goeie week rond te zijn met dit Doel? Vul de Sprint aan met overige prio items (of todo's uit bv de Retrospective). Het Sprint Doel bepaalt wat belangrijk is om op te focussen tijdens de Sprint. Is de realiteit anders dan verwacht, dan zullen de PBIs die niet bijdragen aan het Sprint Doel als eerst af vallen.
Een reactie
[…] start van de Sprint, tijdens de Sprint Planning, wordt het Sprint Doel besloten. Het Sprint Doel is de guiding star richting de Waarde die het […]