Snelheid: waarvoor dient deze en hoe berekent u deze?

Snelheid is een input voor prognoses, geen KPI. Zodra u teams hierop beoordeelt, wordt het cijfer opgeblazen.

De velocity is het gemiddelde aantal story points dat een team per sprint heeft voltooid gedurende de afgelopen paar sprints. Dat is de volledige definitie. Het dient slechts één doel: het voorspellen van het aantal sprints dat nodig is om een backlog op te leveren, uitgaande van het daadwerkelijke leveringstempo van het team. Tel de resterende punten bij elkaar op, deel dit door de velocity, en u krijgt een prognose. Dat is eerlijk gezegd het enige waarvoor het dient.

Elk ander gebruik doet afbreuk aan het concept. „Waarom was de velocity deze sprint lager?“ verandert elke retrospective in een verdediging van het cijfer. „Team A heeft een hogere velocity dan Team B“ beschouwt de onafhankelijke kalibraties van twee teams als vergelijkbaar, terwijl dat niet het geval is. “We moeten de velocity dit kwartaal met 20% verhogen” geeft het team de opdracht om het cijfer omhoog te krijgen, en dat zal het team ook doen — door hetzelfde werk groter te maken, niet door er meer van te doen. De wet van Goodhart, toegepast op een cyclus van twee weken.

Hoe berekent u dit?

Neem de punten die in elk van de laatste drie tot vijf sprints zijn behaald. Bereken het gemiddelde daarvan. Dat is uw velocity. Houd geen rekening met „uitzonderlijke” sprints — die uitzonderlijke sprints maken juist deel uit van het signaal dat u probeert af te vlakken. Tel overgedragen werk niet dubbel. Tel gedeeltelijk voltooide stories helemaal niet mee; deze worden meegeteld in de sprint waarin ze daadwerkelijk worden afgerond. Hoe eenvoudiger de berekening, hoe moeilijker het is om het systeem te manipuleren.

De snelheid stabiliseert zich nadat een team drie of vier sprints samen heeft gelopen. Een nieuw team, een nieuw referentieverhaal, een ingrijpende personeelswijziging — allemaal redenen om het eerdere cijfer terzijde te schuiven en helemaal opnieuw te beginnen. Het cijfer is geen eigenschap van de techniek; het is een eigenschap van dit team in deze periode. Een team dat gisteren twee leden heeft verloren, heeft de velocity van gisteren voor een ander team.

Hoeveel storypoints per sprint?

Zoeken op „hoeveel story points per sprint” is een categorievergissing. Er bestaat geen standaardcijfer voor de sector, geen „goed” aantal, geen vast aantal per ontwikkelaar per dag. Velocity is de gemeten doorvoer van het team, en de enige bruikbare waarde is het voortschrijdend gemiddelde over de laatste paar sprints van het team zelf. Vijftien punten, veertig punten, honderd punten — geen enkel getal is goed of fout. Ze worden afgestemd op de referentiestory van het team.

Gebruik de velocity dus om drie dingen te doen, en slechts drie: een datum te schatten voor een bekende scope (scope ÷ velocity = aantal sprints); bepaal wat er in de volgende sprint past (kies verhalen totdat deze samen ongeveer 80–90% van het recente gemiddelde bedragen, waarbij u ruimte laat voor het onvoorziene); en signaleer wanneer er iets is veranderd (een daling van 30% is een signaal dat een retrospectief gesprek rechtvaardigt). Wat u er niet mee kunt doen: het vergelijken met de cijfers van een ander team, het gebruiken om het team te beoordelen, of het omrekenen naar „verwachte uren per ontwikkelaar per dag“. Elk van deze handelingen is dezelfde fout, maar dan in een ander jasje.

Wat gaat er mis?

De meest voorkomende vorm van mislukking: een manager interpreteert een velocity-cijfer als „hoe productief is dit team?”. Dit cijfer wordt aangehaald tijdens statusvergaderingen, vervolgens vergeleken tussen teams onderling en daarna als streefdoel gesteld. Binnen twee sprints heeft het team zijn story-grootte aangepast om het cijfer te verhogen — elke story is nu 30% groter dan voorheen — en heeft de velocity niet meer dezelfde betekenis als voorheen. De prognose die hiermee bedoeld was, klopt nu niet meer.

Ten tweede: het vergelijken van teams. Twee teams die dezelfde backlog inschatten, komen tot verschillende velocity-cijfers omdat zij verschillende referentiestories hanteren — dat is nu juist de essentie van relatieve inschatting. Het vergelijken ervan is te vergelijken met het vergelijken van twee thermometers met verschillende nulpunten. De cijfers hebben niet dezelfde betekenis, en door ze te behandelen alsof dat wel zo is, wordt de kalibratie van beide teams verstoord.

Wanneer moet er opnieuw worden geraamd?

Het opnieuw inschatten van voltooid werk remt de voortgang af. Het opnieuw inschatten van overgedragen werk is het enige eerlijke geval.

Elk kwartaal duikt dezelfde vraag op: „We hadden dit ingeschat als een 5, maar het bleek in werkelijkheid een 13 te zijn — moeten we dit bijwerken?” Het instinct dat ‘ja’ zegt, is hetzelfde instinct dat wil dat elk cijfer achteraf gezien correct is, en dat is onjuist. Velocity is de snelheid waarmee het team — op basis van de kalibratie die het op dat moment had — het werk heeft voltooid. Teruggaan en de punten herschrijven, betekent ook dat de kalibratie wordt herschreven, en de prognose die voorheen werkte, werkt dan niet meer. “Het team is sneller geworden, dus oude stories zouden kleiner moeten zijn” neemt het enige signaal weg dat het team vooruitgang heeft geboekt. “Deze 5 bleek een 13 te zijn” is een signaal om de volgende soortgelijke story beter in te schatten, niet een vrijbrief om de geschiedenis van deze story te herschrijven.

Het enige geval waarin u de schatting moet herzien, is bij overdracht. Een story is niet afgerond, de sprint loopt ten einde en het resterende werk wordt overgeheveld naar de commitment van de volgende sprint. Dat resterende werk verschilt wezenlijk van wat in het begin was ingeschat — het team heeft een deel ervan voltooid, is op minstens één onbekende factor gestuit en heeft een duidelijker beeld van wat er nog overblijft. Stem er opnieuw over alsof het nieuw is, en gebruik de oorspronkelijke schatting daarbij als een controle in plaats van als een beperking.

Het harmoniseren van de werkwijze tussen de teams

Normalisatie is vooral een SAFe-ritueel om ervoor te zorgen dat de cijfers in een portfoliodashboard kloppen. Weersta de neiging hiertoe, tenzij iemand in een hogere functie dat dashboard daadwerkelijk nodig heeft.

Door normalisatie komen twee of meer teams overeen over een gemeenschappelijk referentiepunt — meestal iets als „één mandag werk voor een gemiddelde ingenieur“ — zodat een 5 bij Team A hetzelfde betekent als een 5 bij Team B, en hun snelheden bij elkaar kunnen worden opgeteld. De techniek werkt: een genormaliseerde 5 betekent inderdaad hetzelfde voor alle teams die hiermee hebben ingestemd. Het probleem is echter wat u hiervoor hebt moeten inruilen. U hebt de relatieve schattingsmethode van elk team ingeruild voor een absolute — wat neerkomt op het schatten van de duur in vermomming — enkel en alleen zodat er een gemiddelde kan worden berekend over teams die geen codebase, stack of domein delen.

Indien een prognose op portfolioniveau daadwerkelijk als basis dient voor de financiering van werkzaamheden (en niet alleen dient om teams met elkaar te vergelijken), voer de normalisatie dan uit op het samenvoegingsniveau: laat het programmamanagement per team een puntenvermenigvuldigingsfactor hanteren, die eenmalig wordt vastgesteld en zelden wordt herzien, en pas deze toe wanneer de cijfers worden samengevoegd. Elk team maakt nog steeds schattingen op basis van zijn eigen referentieverhaal; de vermenigvuldigingsfactor zet de teamvelocity om in de ‘valuta’ van de portfolio, en deze komt nooit ter sprake tijdens verfijningsvergaderingen. Waar u zich tegen moet verzetten: normalisatie die binnen één enkel team begint, en normalisatie die wordt toegepast om teamvergelijkingen te vergemakkelijken. Dat tweede geval is geen gebruiksscenario — het is een antipatroon met een fraaie naam.

Velocity en AI-programmeerhulpmiddelen

Copilot, Cursor, Claude Code. De punten veranderen niet. De snelheid wel — en pas achteraf.

De vraag komt bij elk team naar voren dat al een paar maanden gebruikmaakt van een AI-codeerassistent: we leveren sneller op, moeten we de omvang van de backlog dan aanpassen? Moet de 3 van het vorige kwartaal nu een 5 worden voor dit kwartaal? Het antwoord is nee, omdat story points nooit datgene hebben gemeten wat is veranderd. Punten meten relatieve complexiteit en onzekerheid; de assistent vermindert de tijd die aan het toetsenbord aan een story wordt besteed, soms aanzienlijk, maar de complexiteit blijft ongewijzigd, de onbekende factoren blijven ongewijzigd, het integratierisico en de randgevallen blijven ongewijzigd. Verlaag een 5 naar een 3 omdat de tool de standaardcode heeft geschreven en u weer in uren gaat schatten.

Wat verandert, is de snelheid. Hetzelfde team dat hetzelfde soort werk met een assistent oplevert, levert meer punten per sprint op dan zes maanden geleden — niet omdat de punten kleiner zijn geworden, maar omdat het team sneller is geworden in het omzetten van punten in opgeleverde code. Dat is het getal dat precies zijn werk doet, en het past zich op natuurlijke wijze aan over de loop van drie of vier sprints. Zorg ervoor dat het referentieverhaal van het team actueel blijft — een verhaal dat is opgeleverd met de tools die zij nu gebruiken — en de kalibratie houdt dan al rekening met de eventuele versnelling die zich voordoet.

Er zijn twee punten waar u op moet letten. „De snelheid is met 30% gestegen, laten we ons inzetten voor nog eens 30% meer” houdt een dubbele telling van de verbetering in: het recente gemiddelde houdt al rekening met het AI-effect, dus pas het niet nogmaals aan. “Alles is kleiner geworden, laten we de backlog opnieuw inschatten” is de hierboven genoemde valkuil van herinschatting — de stories zijn niet kleiner geworden, het team is sneller geworden en de prognose weerspiegelt dit al. Onzekerheid is juist het gebied waarop de hulpmiddelen het minst helpen: een assistent versnelt delen van het onderzoek van een spike, maar hetgeen de spike probeert te achterhalen, is er niet kleiner op geworden.

Veelgestelde vragen

Hoeveel story points per sprint is gebruikelijk?

Er bestaat geen standaardcijfer voor de sector. Velocity is de gemeten doorvoer van uw team — het voortschrijdend gemiddelde van het aantal voltooide punten over de afgelopen paar sprints. Vijftien, veertig, honderd: geen enkel getal is goed of fout, omdat elk getal is afgestemd op een ander referentieverhaal.

Hoeveel storypoints per sprint per ontwikkelaar?

Reken er geen uit. Een tarief per ontwikkelaar maakt van story points weer verkapte uren en nodigt uit tot vergelijkingen tussen personen, iets wat deze techniek juist tracht te vermijden. Velocity is een teamcijfer, geen optelsom van individuele quota.

Hoeveel story points telt een sprint van twee weken?

Hoeveel uw team in het verleden ook heeft afgerond in een sprint van twee weken — meet dit, maar stel het niet als doel. Kies verhalen totdat deze samen ongeveer 80–90% van uw recente gemiddelde bedragen, en houd ruimte over voor onvoorziene zaken.

Wat is een goede velocity voor een scrumteam?

Een stabiele. „Is onze doorloopsnelheid goed?“ is de vraag die het systeem ondermijnt — zodra de doorloopsnelheid wordt beoordeeld, lopen de cijfers op en wordt er in werkelijkheid niets sneller geleverd. Een goede doorloopsnelheid is een snelheid waarop u kunt plannen, niet een getal dat maar blijft stijgen.

Aanbevolen lectuur

• Story points versus uren — waarom de omrekening van punten naar uren juist de foutbron is die door ‘velocity’ wordt vervangen.
• Snelheids- en capaciteitsplanning — het gebruik van snelheid om een realistische sprintverplichting vast te stellen.
• Wat is een burndown-grafiek? — hoe teams bijhouden welke punten zij zich binnen een sprint hebben voorgenomen te realiseren.
• Handleiding voor agile schattingen — het volledige overzicht van schattingsmethoden.
• Gratis Planning Poker voor agile teams — schat de punten in waaruit de velocity wordt berekend.