Sprintcapaciteit plannen voor softwareteams

Waarom teams sprint na sprint te veel toezeggen

Te veel toezeggen komt zelden door optimisme over het werk. Het komt door rekenwerk dat begint bij beschikbaarheid die niemand heeft.

• Aantal mensen wordt als capaciteit gebruikt. Vier developers, twee weken, veertig dagen. Niemand heeft veertig dagen.
• Verlof komt te laat ter sprake. Iemand noemt tijdens de planning een vakantie, iedereen knikt, en het sprinttotaal blijft staan.
• Support is niet begroot. De contracttickets die halverwege binnenkomen stonden nergens in het plan, dus worden ze betaald uit het functiewerk.
• De velocity van gisteren wordt de belofte van morgen. Velocity is een meting, geen toezegging, en ze is gemeten in een sprint met andere beschikbaarheid.
• Parttime wordt naar boven afgerond. Vier dagen per week wordt "eigenlijk fulltime" in de spreadsheet.

De berekening, in vijf aftreksommen

Begin bij de kalender in plaats van bij de teamgrootte, en trek in deze volgorde af. Doe het per developer, want gemiddelden verbergen juist die ene persoon die weg is.

Veertig werd tweeëntwintig. Dat is geen pessimisme, dat is hetzelfde team eerlijk beschreven. Teams die plannen op het eerste getal en leveren op het tweede, concluderen dat ze traag zijn. Ze zijn niet traag, ze worden afgerekend op een fictie.

Story points of uren?

Allebei, voor verschillende vragen. Story points zijn goed in relatieve omvang en slecht in plannen. Uren zijn goed in plannen en slecht in het schatten van onbekend werk. Bureaus hebben beide nodig, omdat ze zich tegenover twee partijen verantwoorden.

De fout die je wilt vermijden is punten omrekenen naar uren met een vaste wisselkoers en die koers vervolgens verdedigen. Volg de verhouding, laat hem de volgende schatting voeden, en beloof hem niet aan een klant.

Reserveer capaciteit voor werk waarvan je weet dat het komt

Elk bureau met onderhoudscontracten heeft een stroom onplanbaar werk: een P1 op dinsdag, een klantvraag die twee uur uitzoekwerk wordt, een deployment die begeleiding nodig heeft. De specifieke tickets kun je niet inplannen, het volume wel voorspellen, want je hebt maanden historie.

Neem de laatste drie sprints, tel de uren op die naar werk gingen dat bij de planning niet in de sprint zat, en reserveer dat percentage. De meeste bureaus komen tussen de 15 en 30 procent uit. Door het expliciet te boeken verandert een terugkerende verstoring in een begrotingsregel, en stopt het dat dezelfde senior developer alles stilletjes opvangt.

Verdeel de belasting over mensen, niet alleen over het totaal

Een sprint kan als geheel kloppen en toch niet leverbaar zijn, omdat het werk op één persoon is gestapeld. Het klassieke geval is de enige developer die de betaalkoppeling kent en zes tickets vasthoudt terwijl twee collega's ruimte hebben.

1. 1Vul per developer op diens eigen capaciteit, niet op het teamtotaal.
2. 2Kijk vóór de start wie te vol zit. Na de stand-up op dag drie is te laat.
3. 3Behandel een knelpunt bij één persoon als kennisrisico en programmeer bewust samen aan een van die tickets.
4. 4Is er een voorstel voor herverdeling beschikbaar, behandel dat dan als een voorstel om over te discussiëren en niet als opdracht. De tool weet niet dat één klant net opnieuw gaat onderhandelen.

Een sprint afsluiten zonder werk kwijt te raken

Onafgerond werk aan het eind van een sprint is normaal. Het kwijtraken niet. Een afsluitproces hoort onafgeronde tickets bewust door te rollen, met drie beslissingen die expliciet worden genomen in plaats van vanzelf:

• Meenemen. Nog steeds geldig, nog steeds als eerstvolgende. Het behoudt zijn historie en schuift door.
• Opnieuw schatten. Wat resteert is niet wat gepland was. Pas de schatting aan vóór het doorschuift, anders erft de volgende sprint een onwaarheid.
• Terug naar de backlog. Het was niet belangrijk genoeg om af te maken, en dat is informatie. Zeg dat, en licht de klant in als die het verwachtte.

Stilzwijgend doorschuiven is precies hoe een backlog de plek wordt waar tickets vergeten worden, dezelfde fout als in voorkomen dat klanttickets blijven liggen.

Verandert AI de capaciteitsrekensom?

Deels, en minder dan de marketing suggereert. Agents kunnen werk uit de wachtrij halen — een planner die de codebase leest, een code-agent die een wijziging doorvoert, een reviewer die tests draait — maar elke run eindigt bij een pull request die een mens leest en merget. Die reviewtijd is echt en hoort in je capaciteit.

De eerlijke manier om ermee te plannen: houd menselijke reviewtijd in de sprint, meet over een paar sprints hoeveel implementatietijd er werkelijk verschoof, en pas aan op basis van bewijs. Over die grens schreven we in AI coding agents voor softwareteams.