Sprintplanning: hoe je een vergadering organiseert die de Sprint overleeft

Er is een reden waarom weersvoorspellingen aangeven dat er een kans van 70% op regen is, in plaats van te beloven dat het precies om 15.00 uur gaat regenen. Ze maken gebruik van de beschikbare informatie, houden rekening met onzekerheid en worden bijgewerkt zodra er nieuwe gegevens binnenkomen. Je kunt je middag nog steeds op basis daarvan plannen, zolang je de voorspelling maar niet als een garantie beschouwt.

Sprintplanning werkt volgens een vergelijkbaar principe. Een Scrum-team beschikt over een productbacklog, een schatting van de beschikbare capaciteit en een doel dat het wil bereiken. Maar sommige details van het werk worden pas duidelijk naarmate de sprint vordert. Als je elk uur van tevoren plant, blijft er weinig ruimte over voor die ontdekkingen, terwijl het zonder een gezamenlijke koers moeilijker is om te bepalen wat aandacht verdient.

Het doel is om overeenstemming te bereiken over een waardevol resultaat en in te schatten hoeveel werk het team kan voltooien om dit te bereiken. Van daaruit kan het team zijn plan aanpassen naarmate het meer informatie krijgt, zonder het sprintdoel uit het oog te verliezen.

Deze gids behandelt de voorbereiding van de backlog, een agenda met tijdsindeling, praktische berekeningen van de capaciteit en een uitgewerkt voorbeeld dat laat zien hoe je het plan tijdens de Sprint kunt aanpassen.

Wat is sprintplanning?

Sprintplanning is een Scrum-gebeurtenis die aan het begin van elke Sprint wordt gehouden om af te spreken wat het team wil bereiken en hoe het het werk zal aanpakken. Hierbij komt het hele Scrum-team bijeen, inclusief de Product Owner, de Scrum Master en de ontwikkelaars. Andere specialisten, zoals ingenieuren voor veiligheid of leidinggevenden die contact hebben met klanten, kunnen ook deelnemen wanneer hun inbreng het team helpt weloverwogen beslissingen te nemen.

Volgens de Scrum Guide moet elke planningssessie drie dingen opleveren: een sprintdoel dat de waarde van het werk toelicht, een selectie van productbacklog-items die dat doel ondersteunen, en een eerste plan voor de oplevering ervan. Samen vormen deze de sprintbacklog, die ontwikkelaars gaandeweg de sprint blijven bijwerken.

De Scrum Guide stelt een maximum van acht uur vast voor een Sprint van één maand, en kortere Sprints hebben doorgaans minder tijd nodig. Met een goed uitgewerkte backlog past de onderstaande agenda binnen twee uur.

Als sommige van deze termen je niet bekend zijn, vind je in onze woordenlijst de basisbegrippen van agile en Scrum.

De drie vragen die tijdens de Sprint-planning worden beantwoord

Elke sprintplanningssessie draait om drie vragen:

De Scrum Guide organiseert de planning rond deze vragen, te beginnen met de waarde die je wilt leveren. Zodra iedereen daar duidelijkheid over heeft, is het makkelijker om te beslissen welke backlog-items aandacht verdienen en hoeveel werk je team redelijkerwijs aankan.

Waarom de Sprint belangrijk is

Het sprintdoel geeft het team iets om naartoe te werken en helpt belanghebbenden te begrijpen wat ze kunnen verwachten. Spreek dit doel af met je Scrumteam voordat de planningssessie afloopt.

Beschrijf een resultaat dat mensen kunnen herkennen, zoals „Proefgebruikers kunnen teamgenoten uitnodigen”, in plaats van een doel voor de werklast zoals „34 story points afronden”. Als er zich een onverwacht probleem voordoet, helpt het doel het team te beslissen welk werk moet worden aangepast, terwijl het beoogde resultaat behouden blijft.

Wat het team deze Sprint kan afronden

Zodra je het eens bent geworden over het doel, is het tijd om uit te werken wat het team realistisch gezien kan opleveren.

Ontwikkelaars selecteren backlog-items in overleg met de Product Owner, waarbij ze rekening houden met de beschikbare capaciteit, eerdere prestaties en de ‘Definition of Done’. Dit is ook het juiste moment om eventuele bestaande toewijzingen te bekijken die van invloed kunnen zijn op de tijd die het team voor het sprintwerk heeft.

Veel teams gebruiken story points om de relatieve inspanning en complexiteit van backlog-items te vergelijken. Een Fibonacci-schaal kan helpen om die discussies te structureren, vooral wanneer de benodigde inspanning onduidelijk is.

Hoe het team het werk gaat uitvoeren

Nadat de backlog-items zijn geselecteerd, bedenken de ontwikkelaars hoe ze deze kunnen omzetten in een voltooid productincrement dat voldoet aan de ‘Definition of Done’. De Scrum Guide raadt aan om grotere items op te splitsen in kleinere werkonderdelen, vaak van een grootte die in één dag of minder kan worden afgewerkt.

Dat betekent niet dat je elk uur van de Sprint tot in detail moet in kaart brengen. Voor de eerste paar dagen is wellicht een gedetailleerder plan nodig, terwijl latere taken open kunnen blijven voor aanpassingen naarmate er nieuwe details naar voren komen. Als je vroege schattingen als vaste toezeggingen behandelt, kan dat het team onder druk zetten om de oorspronkelijke cijfers te halen, zelfs als de scope halverwege verandert.

Zoals Dave West, CEO van Scrum.org, uitlegt:

Een prognose die wordt gebruikt om een deadline te verdedigen, nodigt juist uit tot gedrag dat het vertrouwen ondermijnt, zoals het opblazen van schattingen, het verbergen van risico’s of het stilletjes herdefiniëren van ‘Klaar’ om een bepaald nummer te halen.

Wat is het verschil tussen sprintplanning en backlogverfijning?

Door de backlog te verfijnen krijgt je team een duidelijker beeld van het komende werk, nog voordat het tijd is om te beslissen wat er in de volgende Sprint thuishoort. Sprintplanning bouwt voort op die voorbereiding om overeenstemming te bereiken over een doel, backlog-items te selecteren en een eerste opleveringsplan op te stellen.

De twee activiteiten dienen verschillende doelen binnen Scrum:

Zorg ervoor dat voldoende aankomende backlog-items voldoende zijn uitgewerkt, zodat het team tijdens de Sprint duidelijke keuzes kan maken. Hoeveel voorbereiding nodig is, hangt af van hoe snel prioriteiten veranderen en hoeveel onzekerheid er nog is. Items die verderop in de backlog staan, kunnen minder gedetailleerd blijven totdat ze dichter bij de selectie komen.

Hoe bereid je je voor op de sprintplanning?

Controleer een paar dagen van tevoren of de backlog in de juiste vorm is en of iedereen over de informatie beschikt die nodig is om beslissingen te nemen. Zo kun je de sessie besteden aan het bespreken van wat er moet worden opgeleverd en hoe je dat gaat aanpakken, zonder dat je elke vereiste helemaal opnieuw hoeft uit te werken.

Hier is een checklist die je kunt doorlopen vóór je volgende Sprint:

Als je de sprintretrospectieve en de planningssessie kort na elkaar inplant, zorg dan dat er in beide voldoende tijd is voor een grondige discussie. De bevindingen van de retrospectieve moeten de basis vormen voor het plan van de volgende sprint, dus zorg ervoor dat geen van beide vergaderingen gehaast aanvoelen.

Agenda voor sprintplanning: een voorbeeld met tijdsindeling voor een sprint van twee weken

Begin voor een Sprint van twee weken met een planningssessie van twee uur, vooral wanneer de backlog al is verfijnd. Houd rekening met extra tijd als het werk complexe afhankelijkheden bevat of als er meerdere beslissingen moeten worden genomen die bespreking vereisen.

Je kunt deze voorbeeldagenda aanpassen aan de behoeften van je team.

Voordat je afrondt, kun je een snelle vertrouwenscheck doen, zoals Fist of Five, waarbij iedereen zijn vertrouwen in het plan beoordeelt met nul tot vijf vingers. Als iemand een lage beoordeling geeft, vraag dan wat de reden voor de bezorgdheid is. Dit kan wijzen op een onopgeloste afhankelijkheid, een te ambitieuze prognose of een vereiste die meer bespreking behoeft.

Het doel is om knelpunten aan het licht te brengen terwijl er nog tijd is om het plan aan te passen.

Sprintplanning uitvoeren in 6 stappen

Zodra je de backlog hebt voorbereid en hebt bevestigd wie er aanwezig is, kun je de planningssessie starten. Het doel hiervan is om het team te helpen zijn prioriteiten en beschikbare capaciteit om te zetten in een plan waarvan het er zeker van is dat het dit kan opleveren.

Stap 1: Evalueer eerder werk en spreek een doel voor de Sprint af

Begin met een kort overzicht van wat is voltooid, wat nog niet af is en of er actiepunten uit de retrospectieve zijn die van invloed zouden moeten zijn op de volgende Sprint. Concentreer je op alles wat de prioriteiten of aanpak van het team zou kunnen veranderen, in plaats van de hele Sprintreview opnieuw te bespreken.

Laat vervolgens de Product Owner het voorgestelde sprintdoel presenteren en uitleggen hoe dit het bredere productdoel ondersteunt. Geef ontwikkelaars de ruimte om vragen te stellen over de reikwijdte, afhankelijkheden aan te kaarten en aanpassingen voor te stellen.

Als het doel bijvoorbeeld is om klanten het afrekenen te laten voltooien zonder contact op te nemen met de verkoopafdeling, spreek dan af hoe een succesvol afrekenproces eruitziet. Omvat dit een betalingsbevestiging en foutafhandeling? Is het automatisch versturen van een ontvangstbewijs essentieel voor de eerste release?

Deze besprekingen helpen je een resultaat te definiëren waar het team naartoe kan werken. De formulering kan veranderen naarmate er backlog-items worden geselecteerd, maar iedereen moet het eens zijn over het uiteindelijke doel voordat de planning wordt afgerond.

Stap 2: Bereken de beschikbare capaciteit van het team

Bepaal, voordat je de selectie van werk uitvoert, hoeveel tijd je ontwikkelaars realistisch gezien aan de Sprint kunnen besteden.

Begin met het aantal werkdagen en de verwachte beschikbaarheid van elke persoon. Houd vervolgens rekening met gepland verlof, Scrum-gebeurtenissen, ondersteunende taken en andere bekende verplichtingen. Als een ontwikkelaar de helft van zijn week besteedt aan het oplossen van productieproblemen, zijn die uren al toegewezen en niet beschikbaar voor gepland sprintwerk.

Een eenvoudige berekening is: Beschikbare capaciteit = Totaal aantal werkuren − Bekende toewijzingen

Een ontwikkelaar met bijvoorbeeld 80 werkuren over twee weken kan 8 uur verlof, 10 uur vergaderingen en 12 uur taken om anderen te ondersteunen hebben. Dat laat 50 uur over, nog afgezien van eventuele extra onzekerheden.

Vergelijk dit cijfer met de prestaties van het team in het verleden. De velocity geeft aan hoeveel werk het team in eerdere Sprints heeft voltooid, terwijl de capaciteit de beschikbare tijd voor deze Sprint weergeeft.

Stap 3: Evalueer het onafgewerkte werk van de vorige Sprint opnieuw

Onvoltooide backlog-items verdienen nog eens extra aandacht voordat je ze aan de nieuwe Sprint toevoegt. Een item dat twee weken geleden belangrijk was, kan inmiddels een andere prioriteit hebben gekregen, of het team heeft wellicht iets geleerd dat van invloed is op de hoeveelheid werk die nog resteert.

Bespreek elk item met de Product Owner en houd rekening met het volgende:

Voor werk dat nog steeds in de Sprint thuishoort, gebruik je de resterende inspanning om in te schatten hoeveel capaciteit ervoor nodig is. Een half afgerond item vereist mogelijk minder werk dan de oorspronkelijke schatting, maar het telt nog steeds als onafgewerkt totdat het voldoet aan de ‘Definition of Done’.

Stap 4: Selecteer backlog-items die het doel ondersteunen

Als je inzicht hebt in je capaciteit en het nog uitstaande werk, kunnen ontwikkelaars de productbacklog-items selecteren waarvan ze denken dat ze die kunnen voltooien.

Begin met items die het sprintdoel direct ondersteunen. Bespreek de acceptatiecriteria, technische afhankelijkheden en eventuele onzekerheden die de oplevering kunnen beïnvloeden. Als een item te groot of onduidelijk is, overweeg dan om het op te splitsen in kleinere delen die binnen de Sprint waarde kunnen opleveren.

Misschien is er ook ruimte voor onderhoud of andere prioriteiten, maar ga na of het aannemen van dat werk het hoofddoel in gevaar zou kunnen brengen.

Hoeveel capaciteit moet je reserveren?

Het plannen van slechts 80% van de beschikbare capaciteit kan een redelijk uitgangspunt zijn voor teams die regelmatig te maken hebben met onverwachte ondersteunende werkzaamheden, maar Scrum schrijft geen vast percentage voor.

Als je team vaak te maken heeft gehad met onderbrekingen, kun je 10–20% van de aangepaste capaciteit reserveren en die marge vergelijken met wat er tijdens eerdere Sprints nodig was. Een team met stabiel werk en weinig onderbrekingen heeft wellicht minder nodig. Een team dat een live dienst ondersteunt met veel incidenten heeft wellicht meer nodig.

Voorkom dat dezelfde toezegging dubbel wordt geteld. Als de geplande ondersteuningsuren al in stap 2 zijn afgetrokken, moet de extra buffer de onzekerheid dekken die buiten die bekende werklast valt. Gebruik de resulterende capaciteit als leidraad voor de discussie, niet als een target dat moet worden gehaald.

Stap 5: Het werk opsplitsen en afhankelijkheden controleren

Zodra je de backlog-items hebt geselecteerd, kunnen ontwikkelaars uitwerken hoe ze deze gaan opleveren. Dit kan inhouden dat grotere items worden opgesplitst in taken voor ontwikkeling, testen, integratie en beoordeling.

Kijk goed naar de volgorde van het werk. Als de afrekeninterface afhankelijk is van de integratie met een betalingsprovider, moet het team weten wanneer die integratie klaar moet zijn. Als een ander team een wijziging in de veiligheid moet goedkeuren, maak dan duidelijk hoe en wanneer die beslissing zal worden genomen.

Plan het directe werk gedetailleerder en laat latere taken open voor verdere bespreking. De Scrum Guide raadt aan om geselecteerde items op te splitsen in kleinere werkitems, doorgaans met een maximale grootte van één dag, maar ontwikkelaars bepalen zelf hoe ze het werk organiseren en verdelen.

Controleer of het plan rekening houdt met de ‘Definition of Done’, inclusief essentiële test- en integratiewerkzaamheden. Als een afhankelijkheid de oplevering zou kunnen verhinderen, bekijk dan de geselecteerde items opnieuw of pas de opleveringsaanpak aan voordat je het plan definitief vaststelt.

Stap 6: Rond de sprintbacklog af en deel deze

Leg het sprintdoel, de geselecteerde productbacklog-items en het initiële opleveringsplan vast op een plek waar het team er toegang toe heeft en deze kan bijwerken. Samen moeten deze duidelijk maken wat het team wil bereiken en welke werkzaamheden nu de aandacht nodig hebben.

Controleer voordat je de vergadering afsluit of iedereen het eens is met het doel en geef iedereen de kans om eventuele resterende zorgen over de prognoses aan te kaarten. Als er een belangrijke afhankelijkheid of capaciteitsprobleem onopgelost blijft, bespreek dan wat er moet veranderen voordat het team aan de slag gaat.

Tijdens de sprint biedt de Daily Scrum ontwikkelaars de gelegenheid om de voortgang richting het doel te beoordelen en de sprintbacklog bij te stellen. Een burndown- of burnup-grafiek kan helpen om veranderingen in de voortgang weer te geven, terwijl de onderliggende taken de details bieden. Als nieuwe informatie van invloed is op de geselecteerde scope, kunnen ontwikkelaars aanpassingen bespreken met de Product Owner zonder het sprintdoel in gevaar te brengen.

Voorbeeld van sprintplanning: een team met 6 ontwikkelaars

Laten we eens kijken hoe deze beslissingen in de praktijk werken.

Stel je voor dat je een sprint van twee weken plant voor een B2B-factureringsproduct. Je team bestaat uit zes ontwikkelaars en heeft het volgende sprintdoel voorgesteld: “Nieuwe klanten kunnen bij het afrekenen met een kaart betalen zonder contact op te nemen met de verkoopafdeling.”

Voordat je backlog-items selecteert, moet je weten hoeveel tijd het team ter beschikking heeft. Ga er voor dit voorbeeld vanuit dat elke ontwikkelaar zes potentiële uren per dag aan geconcentreerd projectwerk kan besteden, vóór aftrek van geplande Scrum-gebeurtenissen en andere verplichtingen.

Zo werkt de berekening van de capaciteit over 10 werkdagen:

Je hebt nu 216 uur voor gepland werk, nadat je een illustratieve buffer van 20% hebt gereserveerd. In de praktijk zou je die marge bepalen op basis van de hoeveelheid ongepland werk dat eerdere Sprints heeft onderbroken.

Kies de werkzaamheden die het sprintdoel ondersteunen

Zodra de capaciteit is vastgesteld, nemen de ontwikkelaars samen met de Product Owner de backlog-items door die betrekking hebben op het uitchecken.

Hier volgt een illustratieve selectie op basis van hun eerste schattingen van de benodigde inspanning per Taak:

Deze schattingen laten 6 uur over binnen de toewijzing voor gepland werk, plus de buffer van 54 uur voor onverwacht werk. Het team heeft ook een verbetering van het dashboard voor rapportage in de productbacklog. Hoewel dit waardevol is, draagt het niet direct bij aan het afleverdoel. De Product Owner en de ontwikkelaars komen overeen om dit voor een toekomstige Sprint te bewaren.

Pas het abonnement aan wanneer er iets verandert

Op dag zes voert de provider een API-wijziging door waardoor een deel van de integratie niet meer werkt. De ontwikkelaars onderzoeken dit en maken een schatting van het benodigde extra werk.

In plaats van door te gaan met de oorspronkelijke taakvolgorde, bespreken ze de gevolgen met de Product Owner. Als de aanpassing binnen de resterende capaciteit past, kunnen ze deze prioriteit geven en de optionele opmaak van ontvangstbewijzen of een andere taak met lagere prioriteit uitstellen. Betalingsbevestigingen en andere essentiële werkzaamheden moeten nog steeds voldoen aan de Definition of Done.

Als de aanpassing omvangrijker is dan verwacht, moeten ze de resterende scope opnieuw beoordelen en nagaan of het doel van de Sprint nog steeds haalbaar is.

Het team kan uiteindelijk minder backlog-items hebben voltooid dan aanvankelijk was voorspeld. Maar als klanten het afrekenen kunnen voltooien zoals bedoeld en het werk voldoet aan de ‘Definition of Done’, is het sprintdoel bereikt.

Voorbeelden van sprintdoelen voor andere teams

Je kunt dezelfde planningsaanpak toepassen op werkzaamheden buiten de softwareontwikkeling, hoewel Scrum zelf een specifiek raamwerk is met vastgelegde verantwoordelijkheden en gebeurtenissen.

Een marketingteam zou bijvoorbeeld een doel kunnen stellen als: „De landingspagina voor het webinar publiceren en bezoekers in staat stellen zich zonder handmatige hulp te registreren.” Een operationeel team zou kunnen streven naar: „Ervoor zorgen dat elke medewerker in de volgende onboarding-groep op zijn of haar eerste dag over de benodigde apparatuur en systeemtoegang beschikt.”

Beide doelen beschrijven resultaten die als leidraad kunnen dienen voor de beslissingen van het team gedurende de Sprint. De backlog-items en opleveringsplannen zullen verschillen, maar het team moet nog steeds rekening houden met zijn capaciteit en overeenstemming bereiken over wat een succesvolle oplevering inhoudt.

Veelgemaakte fouten bij sprintplanning en hoe je deze kunt verhelpen

Sprintplanning kan op problemen stuiten wanneer teams story points gebruiken om individuele prestaties te beoordelen, onduidelijke backlog-items meenemen naar de vergadering, werk te rigide toewijzen of testvereisten en externe afhankelijkheden over het hoofd zien.

Met een paar aanpassingen kun je deze problemen opsporen voordat ze de oplevering beïnvloeden.

Als dezelfde problemen zich in meerdere Sprints blijven voordoen, breng ze dan ter sprake tijdens de Sprint-retrospectieve en spreek een aanpassing af die je tijdens de volgende Sprint kunt testen. Deze sjablonen voor Sprint-retrospectieven kunnen je helpen bij het vastleggen van observaties en vervolgacties.

Gebruik aan het einde van de sprint de sprintreviewvergadering om samen met de belanghebbenden het voltooide increment te beoordelen en te bespreken wat het team vervolgens moet aanpakken.

Hoe voer je een sprintplanning uit in ClickUp?

Sprintplanning kost meer moeite wanneer taken, capaciteitsschattingen en planningsbeslissingen verspreid zijn over verschillende tools. ClickUp brengt die informatie samen, zodat het team het werk naast de capaciteit kan bekijken en planningsbeslissingen kan herzien wanneer het plan verandert.

Begin met het ClickUp-sjabloon voor agile sprintplanning. De weergaven van de backlog, de ontwikkelingsstatus en de middelen helpen je om het komende werk te bekijken en je voor te bereiden op de planningsbespreking.

Download het gratis sjabloon

Zo pak je de sleutelbeslissingen aan:

Vraag Brain² vóór de volgende planningssessie: „Welke onopgeloste afhankelijkheden kwamen naar voren tijdens onze laatste sprintplanningssessie?“ Brain kan context ophalen uit vastgelegde vergaderaantekeningen. Controleer die details aan de hand van de huidige taken voordat je ze gebruikt om de volgende prognose op te stellen.

Prijzen van ClickUp

Hoeveel moet je plannen voordat een sprint begint?

Na een sprintplanningssessie moet het team voldoende duidelijkheid hebben om aan het werk te kunnen gaan.

De bovenstaande agenda met tijdsindeling en het capaciteitsvoorbeeld vormen een startpunt. Pas ze aan de werklast van het team aan en vergelijk vervolgens de prognose met het voltooide werk en de onderbrekingen om de volgende sprint te verbeteren.

In ClickUp kun je planningsaantekeningen koppelen aan sprinttaken en de sprintbacklog bijwerken naarmate het werk verandert. Het team kan teruggrijpen op het afgesproken plan bij het bepalen van eventuele aanpassingen.

Veelgestelde vragen over sprintplanning

Wat is het verschil tussen sprintplanning en releaseplanning?

Sprintplanning richt zich op wat je team tijdens één Sprint wil bereiken en hoe het dat werk gaat opleveren. Releaseplanning kijkt naar de langere termijn, bijvoorbeeld welke functies in meerdere sprints beschikbaar zouden kunnen komen en wanneer gebruikers deze kunnen verwachten. Releaseprognoses kunnen veranderen naarmate teams meer informatie krijgen, terwijl elk Sprint-doel richting geeft aan het werk binnen de huidige Sprint.

Heb je een ‘Definition of Ready’ nodig voor de sprintplanning?

Nee. Scrum vereist geen formele ‘Definition of Ready’. Sommige teams gebruiken er wel een om voorafgaand aan de selectie gezamenlijke verwachtingen voor backlog-items vast te stellen, zoals duidelijke vereisten, een beheersbare omvang en bekende afhankelijkheden. Houd deze criteria licht genoeg om de discussie te ondersteunen, zonder dat het team wordt belemmerd om items waar nodig te verfijnen.

Kan een sprint na de planning worden geannuleerd?

Ja. Alleen de Product Owner kan een Sprint annuleren, en annulering is een optie wanneer het doel van de Sprint achterhaald raakt, bijvoorbeeld omdat de zakelijke prioriteiten of de marktomstandigheden aanzienlijk zijn veranderd. Een moeilijke Taak of een onnauwkeurige schatting op zich is niet per se voldoende reden voor annulering.

Wat is het verschil tussen een Sprint en agile?

Agile is een bredere benadering van werkbeheer, gebaseerd op de waarden en principes van het Agile Manifesto. Een Sprint is een vaste periode van maximaal één maand binnen het Scrum-raamwerk, waarin een team werkt aan een Sprint-doel en een bruikbaar increment oplevert. Je kunt de Agile-principes volgen zonder gebruik te maken van Sprints. Kanban ondersteunt bijvoorbeeld een continue werkstroom zonder dat er iteraties van vaste lengte nodig zijn.

Kan één sprint meerdere sprintdoelen hebben?

Scrum definieert één sprintdoel als de enige doelstelling van de sprint. Je kunt backlog-items selecteren die andere prioriteiten ondersteunen, zolang ze dat doel niet in gevaar brengen. Als je team regelmatig meerdere, onderling niet-gerelateerde doelen nodig heeft, bespreek dan of het werk bijdraagt aan een breder, gezamenlijk resultaat of dat je concurrerende prioriteiten moet oplossen voordat je gaat plannen.

Moet je tijdens de Sprint planning bugs in story points inschatten?

Storypoints zijn optioneel in Scrum, ook voor bugs. Teams die bugs inschatten, moeten afspreken wanneer en waarom ze dat doen. Bekende defecten kunnen tijdens de planning worden beoordeeld, terwijl bugs die tijdens de ontwikkeling worden ontdekt, mogelijk vallen onder het werk dat al nodig is om aan de ‘Definition of Done’ te voldoen. Voorkom dat dezelfde inspanning dubbel wordt geteld.