Hoe meet je flow? De vier metrics die wél iets zeggen

"Hoe gaat het met het team?" Op die vraag krijg ik meestal een antwoord over velocity, over hoeveel punten er zijn gehaald of over hoe druk iedereen het heeft. Dat zegt iets over inspanning, maar bijna niets over de vraag die er echt achter zit: komt het werk er ook doorheen?

Daar gaan flow-metrics over. Ze meten geen inspanning maar beweging: hoe werk je systeem binnenkomt, doorstroomt en eruit komt. Ze zijn eenvoudig, ze zijn objectief, en — dat is het mooie — je hebt de data er meestal al voor.

Waarom velocity hier niet bij staat

Velocity is de som van story points per sprint. Punten zijn een relatieve schatting die alleen binnen één team betekenis heeft. Twee teams die "20 punten" halen, doen geen vergelijkbaar werk. En omdat het team zelf de punten bepaalt, is de metric te beïnvloeden: als er om meer punten wordt gevraagd, komen er meer punten. Niet meer waarde.

Flow-metrics meten tijd en aantallen. Een dag is een dag, bij elk team. Daarom zijn ze bruikbaar in een gesprek met een directie, en velocity niet.

1. Throughput — hoeveel krijg je af?

Throughput is het aantal items dat je per periode afrondt. Bijvoorbeeld: acht items per week. Geen punten, geen weging, gewoon tellen.

Dat "geen weging" voelt ongemakkelijk — items zijn immers niet allemaal even groot. In de praktijk maakt dat minder uit dan je denkt: over voldoende items heen vlakken die verschillen uit, en dan blijkt throughput opvallend stabiel. Stabiel genoeg om ermee te voorspellen, zonder één schatting te maken.

Waar het je op wijst: een throughput die met horten en stoten gaat, duidt zelden op wisselende inzet. Meestal wijst het op werk dat ergens blijft liggen, of op items die veel te groot zijn opgezet.

2. Cycle time — hoe lang is iets onderweg?

Cycle time is de tijd tussen "we zijn eraan begonnen" en "het is klaar". Meet je die van alle items, dan krijg je geen gemiddelde maar een verdeling — en die verdeling is de kern.

Want een gemiddelde van tien dagen is misleidend als de helft in drie dagen klaar is en een enkel item er vijftig over doet. Kijk daarom naar percentielen: "85% van ons werk is binnen twaalf dagen klaar" is een uitspraak waar een klant iets aan heeft. Een gemiddelde is dat niet.

Waar het je op wijst: de uitschieters zijn de interessantste gevallen. Wat maakte die items anders? Wachten op iemand anders, onduidelijke opdracht, verborgen complexiteit? Daar zit je verbetering, niet in harder werken aan de items die al snel gaan.

3. Work in progress — hoeveel doe je tegelijk?

WIP is simpelweg het aantal items dat op dit moment open staat. En het is de enige van de vier die je direct kunt beïnvloeden — daarom is het de krachtigste.

Hier komt Little's Law om de hoek. Zonder wiskunde: gemiddelde cycle time = WIP ÷ throughput. Zet je twee keer zoveel werk tegelijk open zonder sneller te worden, dan verdubbelt je doorlooptijd. Alles duurt langer, terwijl iedereen het gevoel heeft dat er méér gebeurt.

Dat is de reden dat WIP-limieten voelen als remmen en werken als gas. Minder tegelijk oppakken is contra-intuïtief en levert bijna altijd snellere levering op.

Waar het je op wijst: is je WIP hoger dan het aantal mensen in het team, dan wordt er structureel geschakeld tussen taken. Elke wisseling kost tijd en aandacht die niet in het werk zit.

4. Work item age — hoe lang staat dit al open?

De vierde is de minst bekende en in de dagelijkse praktijk de nuttigste. Work item age is de tijd die een nog niet afgerond item al onderweg is.

Het verschil met cycle time is belangrijk: cycle time kijkt achteruit naar wat klaar is, work item age kijkt naar wat nú vastloopt. Daarmee is het de enige van de vier waarmee je nog kunt ingrijpen.

Weet je dat 85% van je werk binnen twaalf dagen klaar is, en staat er een item op dag elf? Dan is dat geen achteraf-constatering maar een signaal, vandaag, in je daily. Precies het gesprek dat een team verder helpt: niet "wat heb je gisteren gedaan?" maar "wat heeft dit item nodig om vandaag verder te komen?".

Cycle time versus lead time: het verschil dat iedereen verwart

Deze twee worden door elkaar gebruikt, en dat leidt tot verwarring in gesprekken met klanten en directies.

• Lead time loopt vanaf het moment dat iemand iets vraagt tot het moment dat het geleverd is. Inclusief alle tijd dat het verzoek in de backlog lag te wachten.
• Cycle time loopt vanaf het moment dat het team eraan begint. Dus zonder die wachttijd.

Lead time is altijd langer of gelijk. En cruciaal: lead time is wat de klant ervaart. Een team kan trots zijn op een cycle time van vier dagen, terwijl de klant zes weken heeft gewacht omdat het verzoek vijf weken in de backlog lag. Beide cijfers zijn waar; alleen de tweede verklaart waarom de klant ontevreden is.

Meet daarom beide. Cycle time vertelt je iets over je proces, lead time over je belofte aan de klant. Zit het verschil vooral in de wachttijd, dan is de oplossing niet harder werken maar scherper kiezen wat je oppakt.

Deze metrics gaan mis zodra ze een afrekeninstrument worden

Eén waarschuwing, en dat is geen bijzaak. Zodra flow-metrics een beoordelingsinstrument worden, gaan ze kapot. Items worden opgesplitst om de cijfers mooier te maken, of pas "gestart" als ze bijna klaar zijn. Je meet dan nog wel iets, maar niet de werkelijkheid.

Flow-metrics zijn diagnostisch, niet beoordelend. Ze zijn er voor het team, om betere gesprekken te voeren over waar het werk vastloopt. Gebruik ze in je retrospective en je daily, niet in een beoordelingsgesprek. Dat vraagt een omgeving waarin het veilig is om te zeggen dat iets vastzit — en daar begint het echte werk vaak.

Van flow naar waarde: de link met EBM

Flow-metrics vertellen je hoe snel en voorspelbaar je levert. Ze vertellen je niet of je de goede dingen levert. Een team kan een uitstekende flow hebben en toch werken aan iets waar niemand op wacht.

Daarvoor kijk je naar de waardegebieden van Evidence-Based Management: wat levert het product nu op, wat valt er nog te winnen, hoe snel kun je leren, en hoeveel ruimte is er om te vernieuwen. Flow-metrics zijn daarbij de motor onder Time-to-Market. Samen geven ze het volledige beeld: doen we het goed, én doen we het goede?

Beginnen met wat je al hebt

Je hoeft hier geen nieuw meetsysteem voor op te zetten. In Jira, Azure DevOps of welk bord je ook gebruikt, staan de datums van statusovergangen al vast. Daarmee heb je alle vier de metrics al in huis.

Een praktische startvolgorde:

• Spreek eerst af wanneer werk "gestart" en "klaar" is. Zonder die afspraak meet je ruis.
• Begin met work item age in je daily. Dat verandert het gesprek onmiddellijk, zonder dat je iets hoeft te bouwen.
• Maak daarna je cycle time-verdeling zichtbaar en spreek een percentiel af waar je op stuurt.
• Zet dan pas een WIP-limiet, met het team, en houd hem een paar weken vol voordat je conclusies trekt.

Voor die eerste stappen heb je geen tool nodig. Wil je het daarna structureel maken, dan gebruik ik een eenvoudig dashboard dat de data die je al hebt vertaalt naar flow- en EBM-metrics — zonder extra registratielast voor je teams.

Waarom dit werkt

Flow-metrics maken van meningen een gesprek over feiten. Niet om teams af te rekenen, maar omdat je pas kunt verbeteren wat je kunt zien. "Ik heb het gevoel dat het langzaam gaat" is moeilijk om iets mee te doen. "85% van ons werk is binnen twaalf dagen klaar, behalve alles waarvoor we op afdeling X moeten wachten" is een concreet aanknopingspunt.

Wil je dit in je eigen team op gang brengen, dan helpt het om er iemand bij te hebben die de metrics kent én het gesprek in het team kan leiden. Dat is precies waar mijn werk als agile coach en Professional Scrum Trainer samenkomt.