samen
werken
De Perfecte Sprint Planning: Video-uitleg, checklist + voorbeelden
Scrum kent 4 meetings. De eerste bijeenkomst is de Sprint Planning. In deze meeting wordt door het gehele Scrum Team een plan gemaakt om het werk in een Sprint succesvol af te ronden. Het eerste deel van dit artikel geeft je een beknopte uitleg: “Wat is een Sprint Planning precies?”. Het tweede stuk biedt verdieping hoe je als Scrum Team alles uit een Sprint Planning kunt halen.
Deel 1: korte uitleg van de Sprint Planning
Wat is het doel van dit overleg?
Het doel van de Sprint Planning is (zoals de naam al suggereert) een gedegen plan maken voor de huidige Sprint. We selecteren het belangrijkste werk van de Product Backlog en plaatsen het op de Sprint Backlog. Daarbij maken we het voor iedereen inzichtelijk wie waar aan werkt.
Welke voorbereiding is er nodig?
De Scrum Master faciliteert de Sprint Planning en nodigt de Product Owner, Developers en eventuele Stakeholders uit. Verder zorgt de Product Owner ervoor dat hij of zij zich heeft voorbereid door de Product Backlog bij te werken en inzichtelijk te maken.
Daarbij is het belangrijk dat de Product Backlog geprioriteerd is op basis van waarde (het belangrijkste werk staat bovenaan). Verder moeten de Product Backlog Items (PBI’s) waar de komende paar Sprints aan gewerkt gaat worden in detail zijn uitgewerkt. Oftewel de PBI’s dienen ‘sprintklaar’ te zijn, zodat ze opgepakt kunnen worden.
Waarom is deze Sprint waardevol?
Het eerste agendapunt wat op de Sprint Planning staat is het Sprintdoel. Kortom, wat is het doel van de Sprint? Welk probleem willen we in deze Sprint oplossen? Waar willen we met ons Scrum Team op focussen?
Je kunt een Sprintdoel zien als één van de grote brokken werk van een project of programma. Stel je bent een Scrum Team bij de bibliotheek en wil de Kinderboekenweek organiseren. Daarvoor zijn een aantal grote werkpakketten: bepaling strategie, ontwikkeling van het programma, logistiek, marketing, inzet vrijwilligers etc. Wellicht dat het verzorgen van de marketing een Sprintdoel kan zijn, maar misschien is dat te groot en worden het zelfs meerdere Sprintdoelen verdeeld over meerdere Sprints.
Vaak heeft de Product Owner, die verantwoordelijk is voor de algehele planning, al over het Sprintdoel nagedacht en komt tijdens de Sprint Planning met een voorstel. Als Scrum Team bediscussieer je het Sprintdoel, zorg je ervoor dat het voor iedereen helder is, en maak je het uiteindelijk met z’n allen definitief.
Wat kunnen we deze Sprint opleveren?
Nadat je het Sprintdoel hebt bepaald kunnen we kijken welke Product Backlog Items we voor de huidige Sprint selecteren. Maar voordat we willekeurig gaan verslepen is het belangrijk om te bekijken wat de capaciteit is van de Developers. Gaan er mensen op vakantie, zijn er feestdagen, of spelen er spannende zaken in het bedrijf waar wij mogelijk veel ad-hoc werk uit verwachten? De Developers stellen op basis van deze vragen en hun daadwerkelijke capaciteit van het verleden hun capaciteit vast.
Product Owner licht PBI’s toe
Vervolgens legt de Product Owner de hoogst geprioriteerde Product Backlog Items van de Product Backlog voor aan de Developers. Hierbij licht de Product Owner elke PBI dusdanig toe dat iedereen deze begrijpt. Het is hierbij aan de Developers de taak om aan de Product Owner kritische vragen te stellen, zodat de Developers precies weten waar ze aan gaan werken.
Items kunnen worden opgedeeld
Wellicht dat een grote PBI wordt gesplitst in kleinere PBI’s. Verder kan er een inschatting gemaakt worden in Story Points via Planning Poker. Dit proces wordt ook wel Refinement genoemd en kan een aparte meeting zijn voorafgaand aan de Sprint Planning. Door dit een week of nog langer van tevoren te doen geeft het je twee belangrijke voordelen.
Waarom de Refinement waardevol is
Ten eerste geeft het de Product Owner bij onduidelijkheid meer tijd om terug te gaan naar de stakeholders. Mocht bij de Sprint Planning een PBI te onduidelijk zijn, dan kunnen we die helaas niet op de Sprint Backlog zetten. Een tweede voordeel is een hele praktische, namelijk het voordeel dat je Sprint Planning minder tijd kost. Dit overleg kan anders wel erg lang duren, wat de concentratie niet ten goede komt.
De PBI’s op de Sprint Backlog zetten
Als het moment is aangekomen dat we de capaciteit van de Developers weten. En duidelijkheid hebben over de hoogst geprioriteerde Product Backlog Items die ‘sprintklaar’ zijn. Dan kunnen de Developers de PBI’s verplaatsen van de Product Backlog naar de Sprint Backlog. Dit doet niet de Product Owner of de Scrum Master, maar de Developers, zodat ze eigenaarschap nemen over de PBI’s. Daarnaast geeft het ook het gevoel dat je zelf in controle bent over de hoeveelheid werk die je in de Sprint Backlog trekt, in plaats van dat een ander het werk erin duwt.
Eenmaal op de Sprint Backlog blijven deze PBI’s nog steeds Product Backlog Items heten en veranderen niet naar Sprint Backlog Items (die term bestaat niet). Bij het verplaatsen moet ook duidelijk zijn welke Developer eindverantwoordelijk is voor welk Product Backlog Item. Dit kan heel simpel door je naam aan een PBI toe te wijzen.
Hoe kunnen we het werk uitvoeren?
De PBI’s staan op de Sprint Backlog, maar deze PBI’s kunnen nog best groot zijn. Vandaar dat onder PBI’s vaak ook nog taken worden aangemaakt. Het is gebruikelijk dat deze taken niet meer dan een dag werk kosten (ze mogen ook kleiner zijn). De Developers bepalen zelf of ze individueel of onderling met elkaar taken maken. Soms gebeurt dit ook in de Refinement meeting of nadat de Sprint Planning is afgelopen. Verder kan er maar één iemand eindverantwoordelijk zijn voor een PBI, terwijl de taken wel door anderen kunnen worden uitgevoerd.
Een voorbeeld van een Product Backlog Item dat geformuleerd is als een User Story:
Als kind, wil ik kunnen stemmen op mijn favoriete boek, zodat ik invloed kan hebben op het boek dat wordt voorgelezen. (Leo)
Taken die hieronder vallen:
- Deadline vaststellen tot wanneer je je stem kan uitbrengen (Leo)
- Manier bedenken zodat een kind niet meerdere keren kan stemmen (Leo)
- Online poll aanmaken (Flora)
- Promotietekst bedenken (Veerle)
- Promotie via nieuwsbrief (Veerle)
- Promotie via onze social mediakanalen (Veerle)
Hoe sluiten we de Sprint Planning af?
Als laatste wordt er nog door de Developers commitment gegeven op de Sprint Backlog. In andere woorden: is deze planning die we nu met elkaar hebben gemaakt realistisch? Door hier ruimte voor te bieden voorkom je dat je een valse start maakt en dat er risico’s over het hoofd worden gezien.
Commitment afgeven kun je bijvoorbeeld doen met een confidence vote. Alle Developers steken gelijktijdig hun hand in de lucht met één tot vijf vingers. Als je één vinger opsteekt betekent het dat het plan compleet waardeloos is. Vijf vingers is een perfect plan en deze Sprint gaat hoogstwaarschijnlijk een groot succes worden!
Mochten de Developers drie of minder vingers opsteken, dan wil je als Scrum Master deze mensen het woord geven om hun zorgen te uiten. Wellicht dat bepaalde angsten weggenomen kunnen worden of dat het een goed punt is dat we moeten meenemen in ons plan.
Hoe lang mag de Sprint Planning duren?
De Scrum Master zorgt ervoor dat iedereen zich aan de vooraf vastgestelde timebox van de Sprint Planning houdt. Bij een Sprint van een maand wordt een maximale timebox van 8 uur aangehouden. Nu denk je waarschijnlijk: “Wow, een hele dag vergaderen, dat is wel héél veel”.
In de praktijk komt het zelden voor dat een Scrum Team acht uur nodig heeft. Het getal is te verklaren als je een Sprint van een maand hebt, waarbij het team 5 dagen in de week zich volledig op het scrummen richt. Daarbij is dan ook de Refinement meeting in de Sprint Planning opgenomen. Dan is 8 uur als maximale tijd goed te verklaren, maar voor het overgrote deel van alle Scrum Teams geldt dat ze die tijd bij lange na niet nodig hebben.
Deel 2: verdieping op de Sprint Planning
Nu je een goed idee hebt wat de Sprint Planning is gaan kijken naar de praktijk. De praktische tips komen uit eigen ervaring, de ervaring van collega’s en de talloze cursisten die elk jaar trainingen bij ons volgen. Dit tweede gedeelte geeft je inzicht hoe je als Scrum Team alles uit een Sprint Planning kunt halen.
Voorbereiding door de Product Owner
Een goede Sprint Planning valt en staat bij een goede voorbereiding van de Product Backlog. Ik heb het met mijn eigen ogen vaak genoeg gezien dat de Product Owner in de Sprint Planning aan de Developers gaat vragen wat prioriteit heeft en wat de Developers denken dat belangrijk is voor deze Sprint.
Op zich hartstikke goed om de mening van de Developers mee te nemen in het afwegingsproces van prioritering van de Product Backlog. Alleen dit zou moeten gebeuren vóórdat de Sprint Planning plaatsvindt. De Product Owner dient uiteindelijk vanuit de input van de Developers, stakeholders, organisatie en eigen ideeën een afweging te maken van de prioritering. Doe je dit pas tijdens de Sprint Planning dan kom je er wellicht achter dat PBI’s nog niet ‘sprintklaar’ zijn. Verder werkt het erg vertragend als iedereen gaat brainstormen over de prioritering. Het is niet voor niets dat deze verantwoordelijkheid maar bij één persoon is belegd, namelijk de Product Owner.
In mijn ervaring kan het voor Product Owners soms lastig zijn om de waarde van elk PBI te bepalen. Als Scrum Master kun je de Product Owner helpen door hem of haar bijvoorbeeld te vragen bij elke PBI: “Welke echte waarde wordt er geleverd? Waarom zouden we dit überhaupt doen? Welke echte gebruiker heeft hier baat bij?” Dit dwingt de Product Owner om na te denken over de kern van deze PBI. Verder zijn er nog tig andere manieren om waarde te bepalen.
Wat te doen als Scrum Master?
Wat is het uiteindelijke doel dat je als Scrum Master wilt bereiken?
(Denk er eerst zelf over na…)
Het hoogste doel dat je als Scrum Master wilt bereiken is dat je jezelf overbodig hebt gemaakt. Dat iedereen in het Scrum Team precies begrijpt wat er gedaan dient te worden en dat alles vanzelf loopt als zelforganiserend team. Dat je met twee vingers in je neus en je voeten op tafel, popcorn kan eten (misschien moet je die twee vingers in je neus maar laten voor wat het is).
Van de Scrum Masters die ik heb begeleid zie ik soms dat de Sprint Planning heel goed gaat als ze erbij zijn, maar dat als ze een keer afwezig zijn het voor het Scrum Team zoeken is wat ze precies moeten doen. Om ervoor te zorgen dat je jezelf overbodig maakt heb ik hier twee praktische tips die je bij je volgende Sprint Planning gelijk kan toepassen.
Tip 1: schrijf de belangrijkste punten op een flip-over
Schrijf de belangrijkste punten van Sprint Planning zoals in deel 1 van dit artikel is gegeven op een flip-over. Dit vormt de agenda. Als je het idee hebt dat er wordt afgeweken van de agenda kom dan niet gelijk in actie, maar blijf nog even op je handen zitten (zelfs al is het moeilijk).
Komen de Developers of Product Owner met een opmerking over de agenda? Top! Dan gaat het hartstikke goed. Mocht dit te lang duren stel dan een vraag als deze: “Op welke agendapunten weten we op dit moment het antwoord?” Deze vraag laat men nadenken over de agenda en waarschijnlijk komen ze dan tot dezelfde conclusie die jij ook al in je hoofd had.
Tip 2: vraag om een cijfer van de meeting
Een andere manier om het team richting zelforganisatie te sturen is door aan het einde van de Sprint Planning aan het Scrum Team te vragen om deze meeting een beoordeling te geven. Je kunt dit doen via een cijfer. Een blije, neutrale of negatieve smiley. Of door het gewoon te vragen. Je doet dit zodat je niet als enige het proces in de gaten houdt, maar mensen actief laat nadenken hoe we het proces nog beter kunnen maken dan het nu al is. Let daarbij wel op dat je het kort houdt, het is geen Sprint Retrospective. Verder kun je deze tip natuurlijk ook toepassen voor de andere Scrum meetings.
Het maken van taken door de Developers
Voor het bedenken van taken die onder een Product Backlog Item of User Story vallen komen teams soms in de problemen. Het gesprek kan soms erg traag gaan als je één-voor-één elke User Story erbij pakt en met iedereen in een groepsdiscussie taken gaat maken. Er zullen misschien één of twee voornamelijk het woord voeren, terwijl de anderen kijken hoe iemand het opschrijft in een online tool als Jira. Vandaar, twee werkvormen hoe je het maken van taken op een andere manier kan invullen.
Mindmap om taken aan te maken
Maak kleine groepjes van twee of drie personen en geef ze een User Story die ze in het midden van een mindmap plaatsen. De woorden die verbonden zijn met de User Story vormen de taken. Zo’n mindmap kun je maken op papier of via brainstorm tooling zoals Miro. Nu kan het zijn dat je erachter komt dat onder bepaalde taken ook nog kleinere taken vallen. In digitale Agile omgevingen zoals Jira kun je bij taken ook een in de beschrijving weer tekst toevoegen die hier uitermate geschikt voor is.
De kracht van stilte
Bij de tweede werkvorm maak je wederom kleine groepjes en laat je de Developers in stilte taken maken zonder met elkaar te overleggen. Nu zullen er heel veel taken dubbel zijn, dat is niet erg. Ga vooral het gesprek met elkaar over de verschillen in taken en hoe anderen deze User Story zouden aanpakken. Hierdoor wordt net als met de mindmap kennis uitgewisseld.
Problemen bij het formuleren van het Sprintdoel
Wanneer is een Sprintdoel goed? Kun je ook meerdere Sprintdoelen formuleren? Moet je altijd een Sprintdoel gebruiken?
Wat als ik meerdere sprintdoelen heb?
Regelmatig kom ik deze vragen tegen bij Scrum Teams. Laten we er daarom op de theorie en praktijk dieper ingaan. In theorie werk je als Scrum Team aan één product en dan is het ook logisch dat je relatief simpel één Sprintdoel kan formuleren. Helaas is de wereld waarin wij leven niet gevuld met potten goud aan het einde van de regenboog en wordt er in één Scrum Team vaak aan meerdere producten gewerkt. Kun je dan eigenlijk nog spreken over één Product Backlog of is het meer een Team Backlog?
Tuurlijk probeer je te focussen en het liefste te werken aan één product, maar soms is dit niet mogelijk. Daarbij zijn wij bij Agile Scrum Group van mening dat je moet nadenken achter de onderliggende principes van Scrum en je af moet vragen of het doel daarvan wordt bereikt. Daarom is het wat mij betreft prima als je aan twee producten werkt je ook twee Sprintdoelen hebt.
Hoe formuleer ik een sprintdoel?
Hoe formuleer je een Sprintdoel dan? Er is geen standaard format waarin een Sprintdoel gegoten dient te worden. Je kunt het verwoorden als een User Story of in losse steekwoorden. Het belangrijkste is dat iedereen begrijpt waar het Sprintdoel voor staat en wat we tijdens deze Sprint als Scrum Team met elkaar willen bereiken. Is dat het geval? Dan ben je goed bezig!
Gebruik Story Mapping
Zoals eerder benoemd bedenkt de Product Owner vaak een Sprintdoel en maak je die uiteindelijk als Scrum Team definitief. Hoe bedenkt de Product Owner zo’n Sprintdoel? Het Sprintdoel zien als één van de grote brokken werk van een product is een manier om ernaar te kijken. Zie het als een feature van een product. Om deze features te bepalen kan het maken van een Story Map verschrikkelijk handig zijn. Wij geven hier een één-daagse training in waarna je in staat bent om zelfstandig een Story Mapping workshop met je team te begeleiden.
Gebruik de bedrijfsvisie
Daarnaast zijn Sprintdoelen vaak gekoppeld met het Productdoel en een Productvisie. Deze kunnen weer zijn afgeleid uit strategische thema’s die op portfolio level vanuit een bedrijfsvisie zijn bepaald. Kortom, als er vanuit de strategie van een bedrijf een duidelijke visie en behoeftes wordt gecommuniceerd naar de Product Owner, dan heeft hij of zij het weer makkelijker bij het opstellen van een Productdoel en daarmee Sprintdoelen.
De Scrum waarden in de Sprint Planning
Hoe zie je de Scrum waarden terugkomen in de Sprint Planning?
Focus:
Als Scrum Master zorg je in de Sprint Planning voor focus door een duidelijke agenda op te stellen. Daarnaast focussen we op een waardevol gesprek door ons te houden aan de afgesproken timebox. Verder heeft de Product Owner van tevoren al de belangrijkste Product Backlog Items geselecteerd die leidend zijn voor het gesprek. Het Sprintdoel biedt focus voor de gehele Sprint en voorkomt de verleiding dat de Developers van al het werk een beetje oppakken.
Courage (moed):
De Product Owner zal soms moedige afwegingen moeten maken door druk vanuit de stakeholders, naaste collega’s en leden van het Scrum Team. Daarnaast dienen de Developers zich uit te spreken als een PBI te complex blijkt te zijn om zelfstandig op te pakken. De Scrum Master is typisch iemand die deze lastige gesprekken aanmoedigt in plaats van het te verzwijgen of vermijden.
Respect:
Uiteraard worden meningsverschillen tijden de Sprint Planning respectvol behandeld. Daarbij is het van belang dat de Developers niet worden overladen met het werk, maar dat er respect is voor de inschattingen die zij van het werk hebben gegeven. Met het pull mechanisme wordt het werk van de Product Backlog naar de Sprint Backlog getrokken in plaats van dat de Product Owner het werk erin zou pushen.
Openness (openheid):
Door open te zijn over de hoeveelheid capaciteit die we tot onze beschikking hebben kunnen we een realistische planning maken voor de Sprint. Verder zijn de Product Backlog en Sprint Backlog transparant waardoor we snel problemen kunnen ontdekken en risico’s kunnen inschatten.
Commitment:
Heel letterlijk wordt er door de Developers aan het einde van de Sprint Planning commitment afgegeven op de Sprint Planning inclusief het Sprintdoel.
Hopelijk heeft dit artikel je inzicht en inspiratie gegeven hoe je de Sprint Planning invulling kan geven. Nu kan ik mij voorstellen dat het in het begin lastig is om dit in goede banen te laten leiden. Daarom helpen wij organisaties met trainingen en begeleiding van de eerste paar Sprints tot het allemaal vanzelf gaat. Wil je hier meer over weten? Neem dan contact met ons op via info@agilescrumgroup.nl of 020 2614 195 en wij helpen je graag verder.
Ook interessant:
- 10 Retrospective vormen met voorbeelden en ideeën
- Product Owner training volgen?
- In-company trainingsoverzicht
Volg ons op LinkedIn (we delen onze blogs met je)
