Sprintplanning: Wat is het & hoe doe je het?
Ben je klaar om het maximale uit sprintplanning te halen? Als agile projectmanager of product owner is het aan jou om ervoor te zorgen dat iedereen op één lijn zit en resultaten levert.
Het is dus tijd om de chaos op te ruimen en die succescriteria scherp te stellen met deze ultieme gids, waarmee je sprintplanning zo georganiseerd wordt dat je Marie Kondo naar de kroon kunt steken! Hoewel een goede agile projectmanagementtool erg nuttig kan zijn, gaat er niets boven menselijke denkkracht en teamwork om een succesvol sprintplan op te stellen.
Daarom neem ik je in deze uitgebreide gids mee door alles wat je nodig hebt om succesvolle sprints te plannen—waaronder het vaststellen van een sprintdoel, de voorbereiding op de sprintplanningsbijeenkomst, het samenstellen van de agenda voor de bijeenkomst en andere best practices.
Create a Free Account to Read More
Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Wat is sprintplanning?
Sprintplanning is de beginfase van een agile ontwikkelcyclus en maakt deel uit van agile projectplanning. Tijdens deze bijeenkomst komt het hele team samen voor een sprintplanningsbijeenkomst om het werk vast te stellen dat in een sprint moet worden uitgevoerd en een plan op te stellen om die doelen te bereiken.
Doorgaans bestaat de sprintplanningsbijeenkomst uit twee onderdelen:
- Het ‘waarom’ en ‘wat’ van de sprint: het team stelt het sprintdoel vast en spreekt af wat er wordt gedaan. Het selecteert de backlogitems uit de productbacklog die in de sprint worden verwerkt. Projectplanningstools met functies voor sprintplanning kunnen helpen bij het organiseren en prioriteren van backlogitems, zodat het team gefocust blijft en op één lijn zit wat betreft de sprintdoelen.
- Het ‘hoe’ van de sprint: de ontwikkelaars bespreken de details van de afzonderlijke backlogitems en splitsen deze op in taken. Elke taak is zo ingericht dat deze binnen één werkdag of minder kan worden afgerond en kan worden gevolgd met een taakbeheertool.
Afhankelijk van de lengte van de sprint duurt de planningsbijeenkomst twee tot acht uur. De bijeenkomst moet worden afgebakend op basis van de lengte van de sprint (bijv. maximaal vier uur voor een sprint van twee weken).
Aan het einde van de bijeenkomst moeten het sprintdoel en de te voltooien taken zijn vastgesteld en moet de sprint officieel zijn begonnen.
Waarom is sprintplanning belangrijk?
Sprintplanning is belangrijk omdat het een duidelijke richting geeft aan de komende sprint van een team. Wanneer deze goed wordt uitgevoerd, kan een sprintplanningssessie het volgende opleveren:
- Een duidelijk, gedeeld begrip van de projectdoelen en -doelstellingen tot stand brengen
- Teams in staat stellen werkitems voor de komende sprint te prioriteren en te selecteren
- Effectieve toewijzing van middelen en tijdbeheer bevorderen
- Samenwerking en communicatie tussen teamleden stimuleren
Al met al is sprintplanning een essentiële voorbereidende stap in Agile projectmanagement. Het legt de basis voor een goed georganiseerde en efficiënte sprint, waardoor teams binnen de vastgestelde tijdslimiet hoogwaardige resultaten kunnen opleveren.
Wie is betrokken bij sprintplanning?
Kort gezegd moet het volledige Scrumteam betrokken zijn bij de sprintplanning en deelnemen aan het Scrumevenement aan het begin van elke sprint. Deze teamleden kunnen bestaan uit:
- De product owner: geeft inzicht in de productvisie, verduidelijkt de vereisten en prioriteert de backlogitems die in de sprint moeten worden opgenomen.
- De Scrum master (in sommige teams agile coach genoemd en niet te verwarren met een projectmanager): faciliteert de bijeenkomst, zorgt ervoor dat de afgesproken werkwijze wordt gevolgd en dat de deelnemers een gezamenlijk begrip van het sprintdoel ontwikkelen.
- De ontwikkelaars: leveren technische expertise en inzicht in de haalbaarheid en de inspanning die nodig is om gebruikersverhalen te implementeren.
Soms sluiten ook belanghebbenden uit het bedrijf aan als adviseurs, wanneer zij een belangrijk perspectief of nuttige kennis kunnen bieden.
Hoe bereid je je voor op de sprintplanningsbijeenkomst?
Voor een effectieve bijeenkomst moet de product owner (PO) de volgende zaken voorbereiden:
- De bevindingen van de laatste sprintreview en sprintevaluatie, evenals feedback van belanghebbenden in de backlog.
- Een overzicht van het werk dat al is gedaan.
Daarnaast moet de producteigenaar zich op een sprintplanningsbijeenkomst voorbereiden door verschillende processen uit te voeren, die ik hieronder uitgebreider zal bespreken. Deze omvatten:
- Het vooraf definiëren van het sprintdoel met bijbehorende geprioriteerde backlogitems die tijdens de planning kunnen worden besproken.
- Het regelmatig verfijnen van de backlog, waarbij de belangrijkste items worden bijgewerkt.
- Het beoordelen van de snelheid en capaciteit van het team voor de volgende sprint.
Ik zal deze drie activiteiten hieronder in detail beschrijven.
Wat is een sprintdoel?
Tijdens de sprintplanning komen de producteigenaar en de ontwikkelaars een specifiek sprintdoel overeen. Het sprintdoel beschrijft het resultaat of de uitkomst van de nieuwe sprint waaraan het team werkt. Het is een kortetermijnmijlpaal op weg naar het eindproduct.
Het doel is dat er aan het einde van de sprint een opleverbaar productincrement is dat klanten al een voordeel biedt.
Wat is een backlog?
Als je producteigenaar bent, is de kans groot dat je de term "backlog" vaker hebt gehoord dan je kunt tellen. Maar wat is het precies? Op een fundamenteel niveau weten we natuurlijk allemaal wat het is: een lijst met taken of functionaliteiten die moeten worden voltooid.
Wanneer het echter aankomt op de details, zoals het verschil tussen een productbacklog en een sprintbacklog, wordt het al snel ingewikkeld, dus maak je klaar en laten we erin duiken!
Productbacklog versus sprintbacklog
Het Scrumteam verzamelt alle gebruikersverhalen, epics en taken die nodig zijn om het eindproduct te creëren in de productbacklog. En de producteigenaar prioriteert de backlogitems, zodat de verhalen met de hoogste waarde voor de klanten bovenaan staan. Deze prioritering gebeurt meestal samen met de ontwikkelaars.
De productbacklog is echter geen definitieve lijst die aan het begin van de ontwikkelingsfase wordt opgesteld en vervolgens wordt afgewerkt. Nee, deze lijst groeit en verandert voortdurend in de loop van de tijd.
De lijst groeit zowel door de kennis die tijdens de sprints wordt opgedaan als door nieuwe vereisten die later ontstaan. Daarom is het regelmatig verfijnen van de backlog noodzakelijk om deze veranderingen te kunnen verwerken.
Stel bijvoorbeeld dat de productbacklog bestaat uit alle verhalen die nodig zijn om een website te creëren, bijvoorbeeld de homepage, het contactformulier en productpagina's. Als het marketingteam zich plotseling realiseert dat het absoluut een bloggedeelte op de website nodig heeft, kan dit aan de backlog worden toegevoegd en overeenkomstig worden geprioriteerd.
In tegenstelling tot de productbacklog bevat de sprintbacklog alleen de backlogitems die voor de huidige sprint zijn geselecteerd en een algemeen sprintdoel.
Backlogitems inschatten
Hoeveel werk kan een team in de sprint voltooien? Dit is een van de centrale vragen die ontwikkelaars tijdens de sprintplanning moeten beantwoorden. Om een voorspelling te kunnen doen, maken ze een inschatting.
Dit kan behoorlijk uitdagend zijn, omdat het team met veel onbekende variabelen te maken heeft. Na verloop van tijd en met de ervaring die het team opdoet tijdens voltooide sprints, worden de inschattingen echter steeds beter.
De snelheid en capaciteit van het team berekenen
Voordat de inschatting kan beginnen, is het essentieel om de gemiddelde prestaties van de vorige sprints (snelheid) en de beschikbare teamcapaciteit voor de komende sprint te kennen. Deze capaciteit kan verminderd zijn door training, vakantie enzovoort.
Op basis van deze overwegingen schat het team de hoeveelheid werk (snelheid) in die het tijdens de sprint kan uitvoeren. Vervolgens beoordeelt het de afzonderlijke backlogitems en kiest het hoeveel items in de sprintbacklog worden opgenomen.
Stel dat de gemiddelde snelheid tijdens de laatste paar sprints 40 storypunten bedroeg (cyclus van 2 weken) en dat er geen aanzienlijke vermindering van de beschikbaarheid van teamleden wordt verwacht. In dat geval plant het team op basis van het aanhouden van dezelfde snelheid (d.w.z. de backlogitems die voor de komende sprint worden geselecteerd, zullen ongeveer 40 storypunten vullen).
Hoewel de gemiddelde tijd om een taak te voltooien meestal kan worden bijgehouden met een goede tool voor tijdregistratie, kun je ook verschillende andere schattingsmethoden gebruiken om agile capaciteitsplanning te doen en de snelheid van je team te bepalen.
Schattingsmethoden: een kort overzicht
Wil je de kunst van het schatten beter begrijpen? Met verschillende methoden en variabelen die een rol spelen, kan het vaak voelen als een intimiderend onderwerp—maar maak je geen zorgen! Door de basis te begrijpen, ben je al snel goed uitgerust om je backlog te schatten.
Storypunten
Veel agile teams die aan langetermijnprojecten werken, schatten hun snelheid in storypunten.
Storypunten zijn een abstracte eenheid die het team gebruikt om de benodigde inspanning te schatten om een backlogitem te voltooien. Dit is gebaseerd op drie criteria:
- Hoeveelheid werk: Hoeveel subtaken moeten worden voltooid om het gebruikersverhaal te voltooien?
- Risico's en onzekerheid: Zijn alle vereisten duidelijk of kunnen er onverwachte vertragingen en wijzigingen optreden?
- Complexiteit van het verhaal: Zijn afzonderlijke subtaken aan elkaar gekoppeld, waardoor de complexiteit van het verhaal toeneemt? En zijn er afhankelijkheden buiten het team?
De Fibonacci-reeks en priemgetallen
Agile planning met behulp van de Fibonacci-reeks en priemgetallen helpt teams voorspellingen te doen die niet alleen intuïtief op optimisme zijn gebaseerd, maar in plaats daarvan worden onderbouwd door principes van numerieke logica.
Als een gebruikersverhaal veel variabelen heeft en qua omvang complex of grootschalig is, betekent het toekennen van een hoger getal op de Fibonacci-schaal dat het team voorbereid is om voldoende middelen en inspanning toe te zeggen om het tot een goed einde te brengen—omdat ze al weten hoeveel werk een dergelijke onderneming met zich meebrengt.
Aan de andere kant krijgen verhalen met minder variabelen of eenvoudigere resultaten lagere getallen toegekend—waardoor tijd en energie nauwkeuriger kunnen worden begroot. Kortom, agile planning haalt hoop en dromen van de vergadertafel en zet er in plaats daarvan harde, tastbare cijfers voor in de plaats!
Houd er echter rekening mee dat storypunten niet noodzakelijkerwijs vergelijkbaar zijn tussen softwareontwikkelingsteams, omdat elk team de omvang iets anders inschat. Dat betekent dat wat team A inschat als een verhaal van 5 SP, voor team B een verhaal van 8 SP kan zijn.
Het schatten van storypunten is ook geschikt voor kleinere teams of projecten, omdat het team met deze methode de taken beoordeelt op basis van de complexiteit en de tijd die nodig is om ze te verwerken. Andere technieken zijn het schatten van de inspanning op basis van T-shirtmaten of de methode van planningspoker.
T-shirtmaten
Het schatten van backlogitems met T-shirtmaten is een interessante aanpak om projecttaken te helpen prioriteren. In plaats van een exact aantal uren of dagen aan een taak toe te kennen, kun je deze een van vier maattypen toewijzen (klein, middelgroot, groot en extra groot), afhankelijk van de mate van complexiteit of onzekerheid.
Het is een vereenvoudigde maar verrassend effectieve manier om ervoor te zorgen dat de juiste taken op het juiste moment worden uitgevoerd—of je nu met kleine, middelgrote of grootschalige projecten werkt, je hoeft alleen maar de maat te kiezen die past. Zorg er wel voor dat iedereen die bij het project betrokken is het eens is over hoe elke maat overeenkomt met een specifiek geschat inspanningsniveau!
Planningspoker
Als je op zoek bent naar een slimme manier om je backlogitems te schatten, waarom probeer je dan niet planningspoker?
Het is een populaire techniek die al bestaat sinds 2002, toen James Grenning de term bedacht.
De aanpak is eenvoudig: teamleden geven anoniem hun schatting door kaarten uit de stapel planningspokerkaarten te kiezen, die verschillende schattingen vertegenwoordigen (d.w.z. het geschatte aantal storypunten voor het item).
Dit moedigt iedereen aan om zijn of haar mening te uiten zonder angst voor een oordeel of spot van anderen. Zodra alle teamleden hun schattingen hebben ingevoerd en er consensus is bereikt, gaat het team verder met het volgende item.
De agenda voor sprintplanning
Je hebt dus alle noodzakelijke voorbereidingen getroffen en bent eindelijk aangekomen bij de sprintplanningsvergadering. De planning van een Scrum-sprint volgt doorgaans de volgende agenda:
- De product owner (PO) presenteert zijn vooraf bepaalde sprintdoel en deelt zijn idee over hoe de waarde van het product in de komende sprint kan worden verhoogd. Het uiteindelijke sprintdoel wordt gezamenlijk door de product owner en de ontwikkelaars bepaald.
- De PO benoemt de (geprioriteerde) items uit de productbacklog die moeten worden geïmplementeerd om het doel te bereiken.
- Het team schat de inspanning voor de afzonderlijke items in, als dit niet al eerder is gedaan (bijv. tijdens de backlogverfijning). Indien nodig verfijnt het team afzonderlijke items of inhoud (bijv. acceptatiecriteria in de vorm van gegeven-wanneer-dan).
- Het team selecteert de productbacklogitems die het vóór het einde van de sprint zal opleveren. Op dit moment bespreekt de product owner de te voltooien taken met de ontwikkelaars op basis van klantwaarde en inspanning. Zijn de geselecteerde items voldoende om het sprintdoel te behalen en waarde voor de klant te creëren? Uiteindelijk beslissen de ontwikkelaars zelf hoeveel werk ze in de sprint op zich nemen. Belangrijk: Deze selectie is geen toezegging aan de product owner en belanghebbenden, maar een voorspelling op basis van de inspanningsinschatting en de gemiddelde teamsnelheid.
- De ontwikkelaars komen vervolgens samen om de geselecteerde backlogitems op te delen in kleinere taken. Idealiter zijn deze werkpakketten zo ingericht dat ze in één dag of minder kunnen worden voltooid.
- De sprintbacklog bestaat uit het gezamenlijk overeengekomen sprintdoel, de te verwerken backlogitems en het plan voor de verwerking ervan.
- Veel teams visualiseren de sprintbacklog en het uit te voeren werk op een Scrum-bord. Elk team heeft zijn eigen bord en gebruikt verschillende kolommen om de voortgang tijdens de sprint vast te leggen. In essentie zouden de drie belangrijkste kolommen van elk bord de volgende moeten zijn: "Te doen", "Bezig", "Gereed".
In de praktijk splitsen veel Scrumteams de sprintplanning op in twee fasen:
In het eerste deel vinden de eerste vier bovenstaande agendapunten plaats. De product owner en het team verduidelijken de vragen: “Waarom is deze sprint waardevol?” en “Wat wordt er in deze sprint geïmplementeerd?” De ontwikkelaars voeren het tweede deel uit zonder de PO en richten zich op de manier waarop ze het geselecteerde werk uitvoeren.
Sjabloon voor de agenda van een sprintplanningsbijeenkomst
Heb je een agendasjabloon nodig voor je sprintplanningsbijeenkomsten? Download ons duidelijke en eenvoudige sjabloon om snel aan de slag te gaan met je sprintplanningsbijeenkomsten. Je vindt er ook een checklist en een e-mailsjabloon voor extra gemak.
Het is tijd om je sprintplanningsbijeenkomsten volgens Marie Kondo in te richten
Met deze uitgebreide handleiding ben je nu goed voorbereid om het maximale uit je sprintplanningssessies te halen. Als je deze handleiding nuttig vond, raden we je ook aan onze handleiding voor bijeenkomsten voor projectplanning te bekijken.
Door de stappen in dit bericht te volgen, zullen product owners er zeker in slagen chaos om te zetten in duidelijkheid en hun teamleden te helpen hun volgende sprint tot een succes te maken. Lees hier meer over het Scrum-framework en andere Scrum-ceremonies, zoals de dagelijkse Scrum.
Om op de hoogte te blijven van meer organisatorische tips en uitgelichte onderwerpen over het uitvoeren van effectieve productgerichte projecten, nodig ik je uit om je te abonneren op de nieuwsbrief van The Digital Project Manager. Van daaruit blijven we inzichten delen van experts uit de sector en projectmanagers van over de hele wereld.
