Hoe bereken je de capaciteit in een sprintplanning?

De sprintplanning is een cruciaal moment voor elk Scrum-team. Het doel is helder: een realistische hoeveelheid werk voor de komende sprint selecteren die het team kan voltooien. De sleutel tot een succesvolle planning ligt niet in gissen, maar in een nauwkeurige berekening van de teamcapaciteit. Dit cijfer vormt de basis voor alle verdere beslissingen en voorkomt overbelasting, stress en teleurstelling.

Capaciteit is meer dan alleen het aantal beschikbare uren. Het is een realistisch beeld van de productieve tijd die het team daadwerkelijk aan sprintwerk kan besteden. Je moet rekening houden met vakantie, ziekte, vaste vergaderingen, opleidingen en andere niet-sprint gerelateerde activiteiten. Zonder deze afwezigheden en interrupties in kaart te brengen, plan je voor een ideale wereld die niet bestaat, met als gevolg onvolledige sprintdoelen en een dalend teammoreel.

Het berekenen van capaciteit is daarom een praktische oefening in transparantie en gezamenlijk begrip. Het dwingt het team om zijn beschikbaarheid concreet te maken en een gezamenlijk commitment aan te gaan op basis van feiten, niet van wensen. Deze berekening is de fundering waarop een betrouwbare sprint backlog wordt gebouwd en het vertrouwen van stakeholders wordt gewonnen. Laten we onderzoeken hoe je deze essentiële meting stap voor stap uitvoert.

Beschikbare uren per teamlid bepalen: vakantie, ziekte en vaste meetings

De theoretische capaciteit van een sprint is zelden de beschikbare capaciteit. Een realistisch plan begint bij het berekenen van de feitelijk inzetbare uren per teamlid, waarbij rekening wordt gehouden met afwezigheid en vaste verplichtingen.

Begin met het totaal aantal werkuren in de sprint. Voor een standaard werkweek van 40 uur en een sprint van twee weken is dit 80 uur. Dit is het uitgangspunt.

Vakantie en vrije dagen trek je hier direct van af. Controleer de teamagenda voor geplande verlofdagen, officiële feestdagen of andere afwezigheid. Een dag verlof betekent 8 uur minder capaciteit (bij een 8-urige werkdag).

Voor ziekte wordt een buffer of een historisch gemiddelde gehanteerd. Omdat ziekte niet planbaar is, wordt vaak een klein percentage (bijv. 10-15%) van de totale capaciteit gereserveerd en niet aan specifieke taken toegewezen. Dit is een proactieve afweging om het plan realistisch te houden.

Vaste meetings en andere niet-sprint werkzaamheden vormen een cruciaal onderdeel. Tel de uren voor terugkerende vergaderingen zoals teamoverleg, refinements, retrospectives en 1-op-1's. Vergeet ook andere vaste taken niet, zoals opleiding, onderhoud of supportdiensten. Deze uren zijn niet beschikbaar voor sprintwerk.

De berekening per persoon ziet er dan zo uit: 80 uur (totaal) - 8 uur (vakantiedag) - 8 uur (vaste meetings) = 64 uur beschikbaar. Vervolgens pas je de teambrede ziektebuffer toe op de som van alle beschikbare uren.

Het resultaat is een gefundeerd en haalbaar aantal uren waarop de sprintplanning kan worden gebaseerd, wat leidt tot betere voorspelbaarheid en minder overbelasting van het team.

Velocity uit vorige sprints gebruiken voor een realistisch werkbeeld

Velocity is de som van de Story Points van alle user stories die het development team gedurende een sprint heeft voltooid en afgeleverd volgens de Definition of Done. Het is geen doel op zich, maar een historische maatstaf die als leidraad dient voor toekomstige planning.

Bereken de velocity door de punten van meerdere afgeronde sprints te analyseren. Neem bijvoorbeeld de laatste drie tot acht sprints. Bereken het gemiddelde van deze waarden om een betrouwbare basis te krijgen. Een eenvoudig gemiddelde is een goed startpunt, maar let op uitschieters. Een te hoge of te lage velocity door bijzondere omstandigheden kan je beter buiten beschouwing laten voor een realistisch beeld.

Deze berekende gemiddelde velocity vormt de kern van je capaciteitsplanning voor de volgende sprint. Als het team een gemiddelde velocity van 30 punten heeft, is het onrealistisch om 50 punten te plannen. Het team gebruikt dit cijfer om in te schatten hoeveel werk het realistisch gezien kan oppakken, gebaseerd op eigen prestaties uit het verleden.

Velocity is niet statisch. Het kan fluctueren door teamwijzigingen, technische schuld of veranderende complexiteit van features. Gebruik velocity daarom niet als prestatie-indicator voor het team, maar puur als een transparant planningsinstrument. Het helpt om verwachtingen van stakeholders te managen door een data-onderbouwd werkbeeld te schetsen.

Tijdens de sprintplanning bespreekt het team de backlog items en schat deze in. Vervolgens selecteert het team items totdat de totale som van de Story Points overeenkomt met de verwachte velocity. Deze methode creëert een haalbare commitment en vergroot de voorspelbaarheid van de leveringen.

Veelgestelde vragen:

Wat is het verschil tussen capaciteit en beschikbaarheid bij sprintplanning?

Capaciteit gaat over de hoeveelheid werk een team kan doen, gemeten in uren of story points. Beschikbaarheid is de kalendertijd die teamleden hebben. Iemand kan wel beschikbaar zijn (aanwezig), maar een lagere capaciteit hebben door trainingen, ondersteuningstaken of andere niet-sprint gerelateerde activiteiten. Voor een goede planning trek je deze niet-sprint activiteiten af van de totale beschikbaarheid om de werkelijke capaciteit voor sprintwerk te bepalen.

Hoe houd je rekening met vakantie en ziekte tijdens het berekenen?

Je begint met het totaal aantal beschikbare uren van het team. Vervolgens verminder je dit totaal voor elke persoon met geplande afwezigheid, zoals vakantiedagen. Voor onverwachte zaken zoals ziekte wordt meestal geen capaciteit gereserveerd. Wel kan een team ervoor kiezen een kleine buffer aan te houden, bijvoorbeeld door de totale capaciteit met 10-15% te verlagen, om ruimte voor onvoorziene gebeurtenissen te creëren zonder de sprint onder druk te zetten.

Moet je ook meetings meenemen in de capaciteitsberekening?

Ja, dat is nodig voor een realistisch plaatje. Vaste sprintmeetings zoals daily stand-ups, planning, review en retrospective kosten tijd. Tel de geschatte duur van deze meetings voor alle deelnemers op en trek dit totaal af van de bruto capaciteit. Zo voorkom je dat je tijd voor ontwikkelwerk vol plant, terwijl een deel al is ingepland voor overleg. Dit leidt tot een haalbaarder plan.

Is rekenen in uren beter dan in story points voor capaciteit?

Beide hebben voor- en nadelen. Uren zijn concreet en direct gekoppeld aan beschikbaarheid, wat handig is voor nieuwe teams. Het risico is een te sterke focus op urenregistratie. Story points meten complexiteit en relatief werkvermogen. Voor capaciteitsplanning op basis van punten kijk je naar het gemiddelde aantal punten dat het team de afgelopen sprints voltooide (de velocity). Dit getal gebruik je als richtlijn voor de volgende sprint. Veel teams vinden story points op termijn beter voor stabiliteit en focus op waarde.

Onze velocity wisselt sterk. Hoe bepaal ik dan een realistische capaciteit?

Bij een wisselende velocity kun je het gemiddelde van de laatste 3 tot 5 sprints nemen als uitgangspunt. Bekijk ook waar de schommelingen vandaan komen. Gingen ze gepaard met wijzigingen in het team, technische problemen of onduidelijke user stories? Bespreek deze punten in de retrospective. Voor de planning kun je vervolgens het laagste recente velocity-getal gebruiken om zekerheid in te bouwen, of een bereik (bijv. 20-25 punten) hanteren. Kies werk dat past binnen de ondergrens, met enkele optionele taken voor als het meevalt.