Sjabloon voor een sprintplanning-agenda voor engineeringteams

Waarom sprints overladen raken

Sprintplanning kent één structurele fout die sjablonen niet voorkomen: teams selecteren de sprintbacklog voordat iemand de capaciteit controleert. Het resultaat is een sprint die er op een whiteboard haalbaar uitzag en tegen woensdag instort, wanneer twee engineers de halve week weg zijn, één ticket in scope verdrievoudigt, en drie items onuitgesproken afhankelijkheden hadden van een service die het platformteam aan het herschrijven is.

De oplossing is eenvoudig en wordt vrijwel nooit gedaan: committeer je aan capaciteit voordat je je aan werk committeert. Het onderstaande sjabloon opent om precies die reden met een capaciteitsevaluatie.

De agenda (kopieer en plak dit)

Duur: 2 uur voor een sprint van 2 weken; 1 uur voor een sprint van 1 week
Vorm: begeleid, met de backlog zichtbaar voor het hele team

Onderdeel 1 — Sprintdoel (10 min)

Eén zin: hoe ziet een geslaagde sprint er van buitenaf uit?
Het doel moet specifiek genoeg zijn dat elk teamlid aan het einde van de sprint kan beoordelen of je het hebt gehaald
Wijs doelen af die slechts een lijst tickets zijn ("de auth-refactor en de billingpagina afronden") — dat is een backlog, geen doel

Onderdeel 2 — Capaciteitsevaluatie (15 min)

Noem elk teamlid bij naam
Voor elk: geplande vakantie, on-call-rotatie, terugkerende vergaderingen, bekende externe verplichtingen
Druk capaciteit uit in beschikbare story points of dagen — niet in aantal koppen
Dit getal is het plafond; selecteer niet meer werk dan het ondersteunt

Onderdeel 3 — Backlogselectie (45 min)

Loop de items met de hoogste prioriteit uit de verfijnde backlog langs
Voor elke kandidaat: heeft het team genoeg om ermee te starten, of zijn er open vragen die vóór de start van de sprint antwoorden nodig hebben? Open vragen horen in de verfijningswachtrij, niet in de sprint
Stop met selecteren wanneer je 80% van de capaciteit bereikt; de resterende 20% vangt uitloop en ongepland werk op

Onderdeel 4 — Acceptatiecriteria (20 min)

Voor elk geselecteerd item: formuleer het criterium dat het klaar maakt
Als het team niet binnen 60 seconden een criterium kan formuleren, is het ticket niet voldoende verfijnd — verplaats het terug naar de backlog
Schrijf het nu in het ticket, in de ruimte; vertrouw niet op "we voegen het later toe"

Onderdeel 5 — Risico’s en afhankelijkheden (15 min)

Wat kan de oplevering van het sprintdoel blokkeren dat het team niet in de hand heeft?
Noem de verantwoordelijke voor de afhankelijkheid; breng het nu naar boven terwijl er tijd is om het vóór het midden van de sprint op te lossen
Onopgeloste afhankelijkheden krijgen een genoemde verantwoordelijke uit het team die ze zal opvolgen

Afsluiting (15 min)

Bevestig dat het sprintdoel nog geldig is gezien het geselecteerde werk
Wijs de notulist voor de sprintsamenvatting aan, of bevestig de opzet van het geautomatiseerde rapport
Bevestig de datum van de volgende planning

Wat de meeste sprintplanning-sjablonen missen

De populairste sprintplanning-sjablonen richten zich op backlog-verfijning en definition-of-done. Beide zijn belangrijk. Geen van beide pakt de planningsfout aan die de meeste sprintmislukkingen veroorzaakt: werk selecteren zonder de beschikbaarheid te controleren.

Een team van vijf engineers op volle capaciteit heeft ruwweg 200 story points beschikbaar per sprint van 2 weken. Een team van vijf met twee engineers op vakantie, één die on-call-rotatie draait en één op een driedaagse offsite heeft er misschien 110. Als je in die tweede sprint 180 points selecteert, ben je al gefaald. De selectiestap is waar de overcommitment gebeurt, en de capaciteit moet eraan voorafgaan.

De tweede leemte is acceptatiecriteria. Teams gaan snel door de planning heen en zijn van plan de criteria later te schrijven. Later gebeurt het niet op hetzelfde niveau van specificiteit. De persoon die in de ruimte een precies criterium zou hebben geschreven, schrijft de volgende dag iets vagers uit het geheugen, of schrijft het helemaal niet. Onenigheid halverwege de sprint over wat "klaar" betekent, is vrijwel altijd te herleiden tot overgeslagen acceptatiecriteria in de planning.

De opeenstapelende kosten van deze leemtes — overladen sprints, ontdekkingen halverwege de sprint, opnieuw bediscussieerde definities — komen duidelijk naar voren wanneer je ze optelt: De vergadertaks.

Waarom sprintplanning-notities lastiger zijn dan ze lijken

Sprintplanning genereert meer informatie dan vrijwel elke andere terugkerende vergadering: het sprintdoel, de capaciteitscijfers, de selectie-onderbouwing item voor item, de acceptatiecriteria per ticket, de verantwoordelijken voor afhankelijkheden, de risicopunten. Een nuttige samenvatting schrijven vereist dat je dit alles vastlegt in een vorm die drie dagen later nog nuttig is, wanneer iemand vraagt "waarom hebben we dat item geschrapt?".

Pavleur genereert het sprintplanning-rapport automatisch aan het einde van het gesprek. Het legt het sprintdoel vast, de geselecteerde backlog met onderbouwing, de acceptatiecriteria zoals verwoord in de vergadering, en de verantwoordelijken voor afhankelijkheden zoals genoemd. Als iemand de backlog of het capaciteitsspreadsheet via het scherm deelde, wordt die visual opgenomen in het rapport naast de discussie — context die tools met alleen audio zoals Otter of Fireflies volledig zouden missen. Wie laat aanschoof of halverwege de sprint een beslissing moet nagaan, heeft het volledige verslag. Voor een vergelijking van hoe dit verschilt van tools met alleen audio: Pavleur vs. alternatieven.

Omgaan met de planwijziging halverwege de sprint

Het sprintplan is een commitment, geen contract. Wanneer iets halverwege de sprint het plan echt onhoudbaar maakt — een productie-incident, een kritieke afhankelijkheid die drie tickets blokkeert, een prioriteitsverschuiving vanuit het leiderschap — is de juiste reactie een snel herplanningsgesprek, geen stille scope-schrapping. Het herplanningsgesprek kost 20 minuten en levert een bijgewerkt sprintdoel op dat de werkelijkheid weerspiegelt. Het alternatief is een sprint die op papier faalt maar informeel is bijgesteld op manieren die niemand opschreef, waardoor de retrospective moeilijker wordt en de velocitycijfers betekenisloos.

Bouw de gewoonte op van expliciet herplannen. Gebruik dezelfde structuur: bijgewerkte capaciteit, herziene selectie, opnieuw verwoord doel. Het kost veel minder tijd dan de verwarring die het voorkomt.