Is snelheid een bruikbare maatstaf? Ons oordeel

Ja, binnen het team; schadelijk daarbuiten. Velocity is een input voor prognoses waarop het team zich baseert; zodra het een doelstelling wordt of wordt gebruikt voor vergelijkingen tussen teams, wordt het opgeblazen en verliest het zijn betekenis. Het hoort niet bij de leveringsstatistieken van DORA.

Vrijwel iedereen in het debat is het erover eens dat ‘velocity’ het team nooit mag verlaten, en toch laat vrijwel elke organisatie dit toch gebeuren. Die kloof vormt de kern van de discussie. Deze maatstaf is voor één taak daadwerkelijk nuttig en voor de overige taken onmiskenbaar schadelijk; het oordeel moet dus genuanceerd zijn.

Het argument dat snelheid nuttig is

Binnen het team levert ‘velocity’ daadwerkelijk resultaat op. Het stelt u in staat om prognoses te maken: deel de resterende omvang door het recente gemiddelde van het team en u krijgt een ruw aantal sprints dat u kunt afronden. Het stelt u in staat om een realistische sprintomvang te bepalen: selecteer stories totdat deze samen ongeveer tachtig tot negentig procent van het recente gemiddelde bedragen, waarbij u ruimte overlaat voor onvoorziene zaken. Bovendien signaleert het daadwerkelijke veranderingen: een daling van dertig procent is een signaal dat een gesprek rechtvaardigt, geen beschuldiging.

De intentie van het management achter ‘velocity’ als prestatiemaatstaf is eveneens legitiem en verdient het om eerlijk te worden vermeld. Leidinggevenden zijn verantwoordelijk voor de oplevering en willen daar inzicht in hebben. „Als we het team op geen enkele manier kunnen meten, hoe weten we dan of het presteert?” is een redelijke vraag, geen uitspraak van een schurk. Het probleem ligt niet in de wens zelf. Het probleem is dat velocity hiervoor het verkeerde instrument is.

Het argument dat snelheid een valstrik is

Richt de snelheid naar buiten en het vertoont voorspelbare patronen. Stel het als doel („verhoog de snelheid dit kwartaal met twintig procent”) en het team voldoet daaraan door hetzelfde werk omvangrijker te maken in plaats van er meer van te doen. Verander een paar „drieën” in „vijven” en het cijfer stijgt zonder dat de output daadwerkelijk toeneemt. Dit is de wet van Goodhart in een cyclus van twee weken, en het is geen hypothetisch scenario: zelfs Mike Cohn, de belangrijkste voorstander van story points, geeft toe dat de geringste aanwijzing dat snelheden zullen worden vergeleken, leidt tot een geleidelijke maar consistente inflatie van het aantal punten.

Een vergelijking tussen teams is nog problematischer, omdat deze weliswaar rigoureus lijkt, maar in feite zinloos is. Twee teams die dezelfde backlog inschatten, komen tot verschillende cijfers omdat zij hun schattingen afstemmen op verschillende referentieverhalen, en dat is nu juist de essentie van relatieve schatting. Het berekenen van gemiddelden of het rangschikken van deze cijfers verstoort de afstemming van beide teams, louter om een dashboard te voeden. Een duidelijk teken dat een organisatie dit verkeerd aanpakt, is wanneer een leidinggevende zijn of haar teams persoonlijk moet beschermen tegen ‘velocity’ als KPI – een oplossing die precies zo lang werkt als die persoon in die functie blijft.

In welke gevallen wij van gedachten zouden veranderen

Wij zouden ‘velocity’ zonder voorbehoud toestaan voor elk team dat het uitsluitend gebruikt voor prognoses en planning, en het nooit buiten de vergaderruimte laat komen. Op die manier gebruikt is het helemaal geen valstrik. Het is gewoon een rekenkundige berekening die het team voor zichzelf uitvoert.

Wij zouden het in twee gevallen volledig achterwege laten. Ten eerste, indien het werk zo uniform is dat het tellen van verhalen even goed voorspellingen oplevert als het optellen van punten; in dat geval vormt de velocity een extra belasting, en is de doorvoer eenvoudiger en moeilijker te manipuleren. Ten tweede, indien de organisatie er niet van af kan blijven het cijfer als wapen in te zetten. Wanneer de spiraal cultureel vastzit en geen enkel individu deze kan tegenhouden, is de eerlijke stap om te stoppen met het produceren van het cijfer dat wordt misbruikt en over te stappen op flow-statistieken die dat niet worden.

De praktische kant van de zaak

• Snelheid geeft het tempo weer, niet de productiviteit. Zeg dit hardop in de vergaderruimte zodra iemand dit voor het eerst interpreteert als een maatstaf voor de output.
• Vergelijk nooit teams, stel dit nooit als doel en reken het nooit om naar verwachte uren per ontwikkelaar. Dit zijn allemaal dezelfde fout, maar dan in een andere gedaante.
• Rapporteer resultaten naar boven toe, niet het aantal punten. De vijf kernindicatoren van DORA – implementatiefrequentie, doorlooptijd voor wijzigingen, percentage mislukte wijzigingen, hersteltijd en het herwerkpercentage van implementaties – meten de prestaties zonder ruimte te bieden voor manipulatie en hebben, in tegenstelling tot punten, voor alle teams dezelfde betekenis. Dat is de set van prestatie-indicatoren die het management daadwerkelijk wenst.
• Pas de waardering van de backlog niet aan wanneer het team sneller gaat werken. De stories zijn niet kleiner geworden. Het team is sneller gaan werken, en de velocity-waarde zal vanzelf stijgen. Het aanpassen van de waardering om de velocity op peil te houden, is alsof de ratel in omgekeerde richting draait, en het verpest de prognose op precies dezelfde manier.

Velocity dient als kompas voor het team, niet als beoordelingsinstrument voor managers. Als u het binnen het team houdt, is het een van de nuttigste cijfers binnen agile. Als u het naar buiten brengt, wordt het het duidelijkste voorbeeld van een ‘Power’-foutmodus dat er bestaat.

Veelgestelde vragen

Is snelheid een maatstaf voor productiviteit?

Nee. Velocity meet het tempo, niet de productiviteit: het geeft aan hoeveel story points een bepaald team per sprint voltooit volgens zijn eigen kalibratie. Het geeft geen uitsluitsel over de vraag of het werk waardevol was, en daar is het ook nooit voor bedoeld geweest. Velocity hoort ook niet bij de leveringsstatistieken van DORA.

Kunt u de snelheid tussen verschillende teams vergelijken?

Nee. Twee teams die hetzelfde werk inschatten, komen tot verschillende snelheidscijfers omdat zij verschillende referentieverhalen hanteren, en dat is nu juist de kern van relatieve schatting. Het vergelijken ervan is te vergelijken met het vergelijken van twee thermometers met verschillende nulpunten. Mike Cohn, die pleit voor story points, geeft toe dat zelfs de geringste suggestie dat snelheden met elkaar zullen worden vergeleken, leidt tot een consistente opdrijving van de punten.

Wat moeten wij aan het management rapporteren in plaats van de velocity?

Rapporteer resultaten, geen puntentotalen. De vijf kernindicatoren van DORA (implementatiefrequentie, doorlooptijd voor wijzigingen, percentage mislukte wijzigingen, tijd die nodig is om de dienstverlening te herstellen en, sinds 2024, het herwerkpercentage van implementaties) meten de prestaties op een manier die geen ruimte biedt voor manipulatie en die voor elk team hetzelfde betekent, al raadt DORA af ze te gebruiken om teams te rangschikken. Velocity blijft binnen het team als input voor de planning; de indicatoren van DORA zijn waar het management daadwerkelijk op moet letten.

Aanbevolen lectuur

• Snelheid: waarvoor deze dient en hoe deze wordt berekend: de mechanica ervan, en waarom deze niet meer klopt zodra deze tot doelwit wordt.
• Storypoints versus #NoEstimates: de strijd in de vroege fase: wat het getal waard is voordat het een prognose wordt.
• Storypoints versus uren: waarom het omrekenen van een van beide naar uren opnieuw het probleem veroorzaakt dat met ‘velocity’ juist wordt vermeden.
• Wat is een burndown-grafiek?: het bijhouden van de toegezegde punten binnen een sprint, een eerlijke weergave van de cijfers.
• Agile Theatre: de ‘Power failure’-modus: hoe maatstaven zoals velocity worden omgevormd tot controle-instrumenten.