Ik zeg het maar meteen, want het is de kern van dit stuk: velocity is een planningshulpmiddel van het team en hoort niet op een dashboard van het management. Niet omdat management geen cijfers verdient — juist wel — maar omdat deze cijfers precies dat kapotmaken wat je wilde meten.

In vrijwel elke organisatie waar ik kom, staat velocity ergens op een sheet. Vaak met de beste bedoelingen: men wil grip, wil weten of het beter gaat, wil kunnen sturen. Begrijpelijk. Maar het effect is voorspelbaar, en ik heb het inmiddels vaak genoeg zien gebeuren om het met stelligheid te zeggen.

Waar velocity vandaan komt

Velocity is de som van de story points die een team in een sprint afrondt. Story points zijn een relatieve schatting: dit item voelt ongeveer twee keer zo groot als dat item. Het is bewust geen tijdseenheid, omdat mensen slecht zijn in het schatten van uren en redelijk in het vergelijken van omvang.

Dat maakt velocity nuttig voor precies één ding: het team helpt zichzelf inschatten hoeveel het de komende sprint ongeveer aankan. Meer was het niet bedoeld. In de Scrum Guide komt het woord niet eens voor.

Waarom het misgaat zodra het omhoog gaat

Zodra velocity een stuurgetal wordt, gaan er drie dingen tegelijk mis.

1. Het team bepaalt zelf de meetlat

Dit is het fundamentele probleem. Het team kent de punten toe. Vraag om een hogere velocity en je krijgt een hogere velocity — binnen twee sprints, zonder dat er iets aan het werk verandert. Dat is geen onwil of bedrog; het is hoe mensen reageren op een meetlat die ze zelf vasthouden. Puntinflatie heet dat, en het is de meest voorspelbare uitkomst die er is.

Vergelijk het met een weegschaal waarbij degene die gewogen wordt zelf mag bepalen wat een kilo is.

2. Punten zijn niet vergelijkbaar tussen teams

Team A haalt 40 punten, team B haalt 22. Wat weet je nu? Niets. De schaal is per team ontstaan, uit hun eigen referentie-items. Toch zie ik dashboards waarop teams naast elkaar staan, met kleurtjes. Dat is geen sturingsinformatie, dat is een ranglijst op basis van verschillende meetlatten — en teams voelen dat feilloos aan.

3. Het duwt de verkeerde kant op

Wat je meet, krijg je. Stuur op punten en je krijgt gedrag dat punten oplevert: werk opknippen zodat er meer items "klaar" zijn, technische verbeteringen uitstellen omdat daar geen punten voor staan, refinement afraffelen omdat overleg geen punten oplevert. Allemaal rationeel gedrag binnen het systeem dat je hebt neergezet. En allemaal schadelijk voor het echte doel.

Het meest verontrustende is wat er met de gesprekken gebeurt. Een schatting hoort een gesprek te zijn over onduidelijkheid en risico. Zodra het cijfer wordt afgerekend, wordt het een onderhandeling. Daarmee raak je precies de waarde kwijt waarvoor je ging schatten.

"Maar we moeten toch iets kunnen sturen?"

Absoluut. En dat kan prima — met cijfers die niet stuk gaan zodra je erop stuurt. De vuistregel: meet tijd en aantallen, geen zelfbedachte eenheden.

  • Throughput — hoeveel items rondt het team per periode af. Gewoon tellen. Een item is een item, ook bij een ander team.
  • Cycle time — hoe lang is werk onderweg. Kijk naar percentielen: "85% is binnen twaalf dagen klaar" is een belofte waar een klant iets aan heeft.
  • Work in progress — hoeveel staat er tegelijk open. De enige die je direct kunt bijsturen, en meestal de snelste winst.
  • Work item age — hoe lang loopt een nog niet afgerond item al. De enige waarmee je vàndaag nog kunt ingrijpen.

Deze zijn objectief, over teams heen te begrijpen, en veel lastiger te manipuleren. Ik ga er dieper op in in hoe je flow meet.

Op welk niveau kijk je?

Een veelgemaakte fout is dat één dashboard voor iedereen moet werken. Dat kan niet: een team heeft andere vragen dan een trein van teams, en een directie heeft weer andere vragen dan beide. Daarom werk ik met drie niveaus, elk met hun eigen gesprek.

  • Scrum flow dashboard — voor het team zelf. Work item age, WIP, cycle time-verdeling en throughput per team. Dit is het dashboard voor de daily en de retrospective: waar loopt werk vandaag vast, en wat kunnen we daar nu aan doen?
  • ART flow dashboard — voor meerdere teams samen (een Agile Release Train of vergelijkbaar verband). Hier gaat het over de doorstroming tussen teams: afhankelijkheden, wachttijd bij overdrachten en features die over teamgrenzen heen lopen. Vertraging zit op dit niveau bijna nooit in het bouwen, maar in het wachten.
  • Management dashboard — voor directie en portfolio. Geen teamcijfers, maar uitkomsten: de waardegebieden uit Evidence-Based Management, lead time zoals de klant die ervaart, en trends over de tijd. Precies hier is de verleiding om velocity op te nemen het grootst — en precies hier richt het de meeste schade aan.

De sleutel zit in wat je per niveau weglaat. Teamcijfers hebben op een managementdashboard niets te zoeken, want ze nodigen uit tot vergelijken tussen teams. En omgekeerd heeft een team weinig aan portfoliocijfers waar het geen invloed op heeft.

Alle drie de dashboards draaien op data die er al is: statusovergangen uit je backlogtool, releasedata en supportgegevens. Geen extra registratielast voor teams, geen apart invulproces. Dat is bewust — zodra meten werk oplevert, wordt er anders geregistreerd en meet je de registratie in plaats van de werkelijkheid.

En de vraag àchter de vraag

Flow-metrics vertellen je hoe snel en voorspelbaar je levert. Ze vertellen je niet of je de goede dingen levert. Een team kan uitstekend doorstromen en toch bouwen waar niemand op zit te wachten.

Daarvoor is Evidence-Based Management bedoeld: kijken naar de waarde die je nu levert, de waarde die je nog laat liggen, hoe snel je kunt leren en hoeveel ruimte er is om te vernieuwen. Dat zijn de vragen waar een directie iets aan heeft. "Hoeveel punten hebben we gehaald?" is dat niet.

Hoe je het gesprek omdraait

Als je velocity van een dashboard af wilt halen, help het niet om te beginnen met "dat mag niet van Scrum". Wat wel werkt, is vragen wat men er eigenlijk mee wil weten. Meestal is dat één van deze drie:

  • Gaat het sneller? → laat cycle time en throughput over de tijd zien.
  • Kunnen we iets beloven? → gebruik de cycle time-verdeling en throughput om te voorspellen, met een betrouwbaarheidspercentage in plaats van een datum.
  • Doen we de goede dingen? → dan hoort het gesprek over waarde te gaan, niet over snelheid.

In mijn ervaring is niemand gehecht aan velocity zelf. Men is gehecht aan het gevoel van grip. Bied een beter alternatief en het loslaten gaat opvallend soepel.

Wil je in je eigen organisatie van puntentellen naar sturen op waarde? Dat is precies het werk dat ik als agile coach en Professional Scrum Trainer doe.