Teamvelocity bij agile: hoe u dit kunt meten en toepassen (+ gratis calculator)

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

Velocity is het gemiddelde aantal story points dat een team per sprint voltooit, berekend over de afgelopen paar sprints. Dat is de volledige definitie. Het dient maar één doel: het inschatten 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 de methode. „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 brengen, en het team zal dat doen door hetzelfde werk groter te maken in plaats van er meer van te doen. Dat is de wet van Goodhart, toegepast op een cyclus van twee weken.

Een eerlijke kanttekening voordat we aan de handleiding beginnen: de Scrum-gids Er wordt geen melding gemaakt van snelheid. Het is een gangbare werkwijze die bovenop Scrum is gebouwd, geen regel ervan, en juist daarom is het de moeite waard om goed na te denken over waarvoor u deze methode inzet.

Hoe berekent u de teamvelocity?

Neem de behaalde punten in elk van de laatste drie tot vijf sprints. Bereken het gemiddelde daarvan. Dat is uw snelheid.

Een praktijkvoorbeeld, verdeeld over drie sprints:

Sprint	Voltooide story points
Sprint 7	21
Sprint 8	34
Sprint 9	26

Snelheid = (21 + 34 + 26) gedeeld door 3 = 27 punten per sprint.

Als er nog 210 punten in de backlog staan, is de prognose 210 gedeeld door 27, wat neerkomt op ongeveer 8 sprints. Aangezien de invoerwaarden varieerden van 21 tot 34, is de eerlijke schatting „zeven tot tien sprints”, en niet „7,8 sprints”. Of sla de berekening over en laat de bovenstaande calculator het voor u uitrekenen.

De regels die ervoor zorgen dat het cijfer betrouwbaar blijft: corrigeer niet voor „uitzonderlijke” sprints, want juist die uitzonderlijke sprints maken deel uit van het signaal dat u probeert af te vlakken. Tel overgedragen werk niet dubbel, en tel gedeeltelijk voltooide stories helemaal niet mee. Deze tellen mee 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 of een ingrijpende personeelswijziging zijn 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.

Het gebruik van velocity bij het plannen van de volgende sprint

Velocity bewijst zijn waarde bij sprintplanning, en de methode is kort:

1. Ga uit van het voortschrijdend gemiddelde van de laatste drie tot vijf sprints; nooit van het resultaat van één enkele sprint, en nooit van uw beste sprint.
2. Houd rekening met bekende wijzigingen in de capaciteit. Zijn er in de volgende sprint twee mensen met verlof? Is er een feestdag? Pas de doelstelling dan al vóór de planning evenredig naar beneden aan, en niet achteraf met een verontschuldigend gebaar. De velocity is gebaseerd op het team dat deze heeft gerealiseerd, en het team van de volgende sprint is soms kleiner.
3. Neem minder dan het gemiddelde op, ongeveer 80 tot 90 procent daarvan. Selecteer verhalen totdat het totaal ongeveer dat percentage bedraagt, en houd ruimte over voor het onvoorziene werk dat elke sprint opduikt, of u daar nu rekening mee houdt of niet.
4. Geef uw prognose in bandbreedtes. Voor alles wat verder reikt dan de volgende sprint, geeft u uw beste en slechtste recente sprints als grenzen aan. Belanghebbenden kunnen hun planning baseren op „zeven tot tien sprints”. Zij kunnen hun planning niet baseren op een exact aantal dat achteraf onjuist blijkt te zijn.

Gebruik de velocity voor drie dingen, en slechts drie: het vaststellen van een streefdatum voor een bekende scope (de scope gedeeld door de velocity levert het aantal sprints op), het bepalen wat er in de volgende sprint past, en het signaleren wanneer er iets is veranderd (een daling van 30 procent is een signaal dat een retrospectiefgesprek 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.

Hoeveel storypoints per sprint?

Zoeken op „hoeveel story points per sprint” is een categorievergissing. Er bestaat geen standaardcijfer voor de sector, geen „goed” cijfer en geen norm 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.

De grote fout: snelheid als prestatiemaatstaf

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 ten slotte als streefdoel gesteld. Binnen twee sprints heeft het team zijn omvangherberekening aangepast om het cijfer te verhogen; elke story is nu 30% omvangrijker dan voorheen, en de velocity heeft niet meer dezelfde betekenis als vroeger. De prognose die hiermee had moeten worden opgesteld, 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 schatting. Het vergelijken van deze cijfers is te vergelijken met het vergelijken van twee thermometers met verschillende nulpunten. De cijfers hebben niet dezelfde betekenis, en door ze wel als zodanig te behandelen, wordt de kalibratie van beide teams verstoord.

Wilt u dat de berekeningen voor u worden uitgevoerd? Ga dan terug naar de gratis snelheidscalculator en voer daar uw eigen sprints in.

Wanneer dient u de raming te herzien?

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 hebben 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 voltooide. 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 opnieuw moet uitvoeren, 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 wijkt wezenlijk af van wat in het begin was ingeschat: het team heeft een deel ervan uitgevoerd, is op minstens één onbekende factor gestuit en heeft een duidelijker beeld van wat er nog overblijft. Beoordeel het opnieuw alsof het nieuw is, en gebruik de oorspronkelijke schatting daarbij als een controle in plaats van als een beperking.

Het harmoniseren van de snelheid tussen de teams

Normalisatie is vooral een SAFe-ritueel om ervoor te zorgen dat de cijfers in een portfoliodashboard kloppen. Vermijd dit, 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 in de trant van „éé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 om een gemiddelde te kunnen berekenen 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 louter 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 teamsnelheid om in de ‘valuta’ van de portefeuille, en deze factor 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, maar een antipatroon met een fraaie naam.

Velocity en AI-programmeerhulpmiddelen

Copilot, Cursor, Claude Code. De punten veranderen niet. De snelheid verandert wel, maar pas achteraf.

Deze vraag komt in elk team naar voren dat al enkele 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. Pas een 5 aan naar een 3 omdat de tool de standaardcode heeft geschreven en u weer in uren gaat inschatten.

Wat verandert, is de snelheid. Hetzelfde team dat met een assistent hetzelfde soort werk 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 cijfer 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 dan houdt de kalibratie al rekening met de eventuele versnelling die er is.

Er zijn twee punten waarop u moet letten. „De snelheid is met 30% gestegen, laten we ons vastleggen op 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 een spike-onderzoek, maar hetgeen dat de spike probeert te achterhalen, is er niet kleiner op geworden.

Samen een schatting maken in TeamRetro

De nauwkeurigheid van Velocity hangt volledig af van de schattingen waarop het is gebaseerd. TeamRetro Estimations voert planning poker uit met uw team, zowel live als asynchroon, zodat de punten die u in deze calculator invoert, voortkomen uit het oordeel van het hele team en niet uit de schatting van één persoon. Probeer TeamRetro Estimations, of begin met de gratis planning poker-tool.

Veelgestelde vragen

Wat is teamvelocity binnen agile?

De teamsnelheid is het gemiddelde aantal storypoints dat een team per sprint voltooit; dit wordt doorgaans gemeten over de afgelopen drie tot vijf sprints. Het is een input voor de planning, die wordt gebruikt om in te schatten hoeveel er in de volgende sprint past en hoe lang het zal duren om de backlog af te werken; het is geen maatstaf voor de kwaliteit van het team.

Hoe berekent u de teamvelocity?

Tel de voltooide story points van elk van de laatste drie tot vijf sprints bij elkaar op en bereken het gemiddelde. Als u in uw laatste drie sprints respectievelijk 21, 34 en 26 punten hebt voltooid, bedraagt uw velocity 27. Tel alleen voltooide stories mee, in de sprint waarin ze zijn voltooid, of gebruik de gratis calculator op deze pagina om de berekening uit te voeren.

Wat is een goede teamsnelheid?

Een stabiele waarde. Er is geen standaardmaatstaf, omdat de punten van elk team worden afgestemd op zijn eigen referentieverhaal; 15, 40 en 100 kunnen dus allemaal gezonde waarden zijn. Een goede velocity is een waarde waarop u uw planning kunt baseren, niet een getal dat maar blijft stijgen.

Moet u de snelheid tussen verschillende teams vergelijken?

Nee. Verschillende teams kalibreren punten aan de hand van verschillende referentieverhalen, waardoor hun snelheden niet in dezelfde eenheden worden uitgedrukt. Het vergelijken ervan is te vergelijken met het vergelijken van twee thermometers met verschillende nulpunten. Een vergelijking tussen teams zet teams bovendien onder druk om schattingen op te blazen, wat de prognoses verstoort die juist met behulp van de snelheid moeten worden opgesteld.

Wat als wij geen schattingen in punten gebruiken, maar bijvoorbeeld T-shirtmaten?

U kunt nog steeds een ruwe doorvoer bijhouden, maar u kunt geen exact snelheidscijfer afleiden uit T-shirtmaten, omdat de maten niet bij elkaar opgeteld kunnen worden. Er zijn twee mogelijkheden. Breng de maten eerst in kaart op een eenvoudige puntenschaal (bijvoorbeeld XS=1, S=2, M=3, L=5, XL=8), tel het totaal aantal voltooide items per sprint en beschouw het resultaat als een ruwe trend in plaats van een nauwkeurig cijfer. Of, als uw items doorgaans ongeveer even groot zijn, tel dan in plaats daarvan de doorvoer: het aantal items dat per sprint is voltooid. Beide methoden zijn minder nauwkeurig dan op punten gebaseerde snelheid, dus beschouw ze als een indicatie van de richting, niet als decimale getallen. Wanneer u een echte prognose nodig hebt, maak dan een nieuwe schatting van het werk op korte termijn in punten. Raadpleeg onze gids over t-shirtmaten voor de omrekening van maten naar punten.

Hoe verwerken wij werkzaamheden die niet als afgemeten posten zijn geregistreerd?

De velocity geeft alleen het werk weer dat u daadwerkelijk in omvang vaststelt en bijhoudt. Supporttickets, vergaderingen, onderbrekingen en bugfixes zonder toegewezen punten nemen nog steeds capaciteit in beslag; als veel van dat werk onzichtbaar blijft, zal uw velocity lager uitvallen dan de werkelijke inspanning van het team en zullen uw prognoses te optimistisch uitvallen. Twee eerlijke oplossingen. Leg het terugkerende, ongeplande werk vast als ingeschatte items, zodat het net als al het andere in de velocity wordt meegenomen. Of reserveer er openlijk capaciteit voor, door ongeveer 80 tot 90 procent van uw gemiddelde vast te leggen en de rest als Slack te laten. Wijs geen punten toe aan onzichtbaar werk alleen maar om het cijfer hoger te laten lijken, want dat verstoort de kalibratie waarvan de velocity afhankelijk is.

Hoe gaat u in Velocity om met herstelwerk?

Hernieuwd werk vergt daadwerkelijk inspanning, maar het opnieuw inschatten van een story die al als voltooid was geteld, verstoort de velocity. Behandel hernieuwd werk als nieuw werk: maak een nieuw item aan, bepaal de omvang ervan en tel het mee in de sprint waarin het wordt voltooid. Open het oorspronkelijke verhaal niet opnieuw en maak geen nieuwe schatting ervan. Als er steeds opnieuw werk opduikt, is dat een signaal over de kwaliteit dat een gesprek tijdens de retrospectieve rechtvaardigt, en geen aanpassing van de velocity. De prognose blijft alleen betrouwbaar als elk punt slechts één keer wordt geteld, in de sprint waarin het werk daadwerkelijk is voltooid.

Hoeveel storypoints 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 methode juist tracht te vermijden. Velocity is een teamcijfer, geen optelsom van individuele quota.

Hoeveel storypoints telt een sprint van twee weken?

Hoeveel uw team in het verleden ook heeft voltooid in een sprint van twee weken: meet dit, maar stel het niet als doel. Kies verhalen totdat deze samen ongeveer 80 tot 90 procent van uw recente gemiddelde uitmaken, en houd ruimte over voor het onvoorziene.

Wat is een goede velocity voor een scrumteam?

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

Aanbevolen lectuur

• Storypoints versus uren: waarom de omrekening van storypoints naar uren juist de foutbron is die door Velocity wordt vervangen.
• Snelheid 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.
• Agile schattingstechnieken: de plaats van velocity binnen het geheel van planning poker, story points en de overige methoden, en wanneer welke techniek het best kan worden toegepast.
• Handleiding voor agile schattingen: het volledige schattingscluster.
• Gratis Planning Poker voor agile teams: schat de punten in waaruit de velocity wordt berekend.