Cycle time vs. lead time: waarom het verschil telt

Smiling person in layered hair w/eyelashes,gesturing

Published on 18 June 2026 by Zoia Baletska

Two measurement spans over one piece of work, one starting earlier than the other.

Cycle time en lead time worden in Agile-gesprekken door elkaar gebruikt, en die verwisseling is makkelijk gemaakt: beide worden in dagen uitgedrukt, beide heten iets te zeggen over snelheid, en beide lopen op als het slecht gaat. Maar ze meten verschillende stukken van dezelfde tijdlijn, en een team kan de ene verbeteren terwijl de andere verslechtert. Dat is geen afrondingsverschil — het is de reden dat engineering en management naar dezelfde levering kunnen kijken en het oneens zijn over de vraag of het snel ging.

Wat cycle time meet

Cycle time is de klok die start zodra iemand het werk oppakt en stopt als het werk klaar is. Alles daarvóór telt niet mee. Een ticket dat een maand in de backlog stond en daarna in twee dagen gebouwd werd, heeft een cycle time van twee dagen.

Daarmee zegt cycle time iets over de machine: hoe lang een stuk werk duurt zodra het iemands aandacht heeft. Het is het getal dat reageert op kleinere batches, minder overdrachten, snellere review en minder schakelen tussen taken — en daarom pakken engineeringteams het als eerste.

Wat lead time meet

Lead time begint eerder en eindigt later. De klok start zodra het verzoek binnenkomt en stopt als het resultaat in productie staat of bij de klant is. Alles daartussen telt mee — inclusief alle tijd waarin niemand eraan werkte.

Daarmee zegt lead time iets over de ervaring aan de andere kant van het verzoek. Iemand vroeg om iets; hoe lang duurde het voor diegene het had? In dat antwoord zitten prioritering, wachtrijen, goedkeuringen en releasemomenten, en geen daarvan is zichtbaar in cycle time.

Eén tijdlijn met vier punten — verzoek binnen, werk start, werk klaar, in productie. Lead time beslaat alle vier; cycle time dekt alleen het stuk tussen starten en klaar zijn. De rest is wachten.

Hetzelfde ticket, twee eerlijke antwoorden

Op maandag komt er een featureverzoek binnen. Het staat twee weken in de backlog te wachten op prioritering. Ontwikkeling duurt vier dagen, review twee, en het gaat mee in de release van de week erna.

Het engineeringteam rapporteert een cycle time van zes dagen en heeft gelijk. Het management heeft drie weken ervaren en heeft ook gelijk. Niemand draait aan het getal; ze lezen verschillende stukken van dezelfde lijn. Zo kan een deliverydashboard er gezond uitzien terwijl stakeholders blijven zeggen dat het traag voelt — het dashboard meet precies het deel dat al snel was.

Waar het gat vandaan komt

Alles wat lead time meet en cycle time niet, is wachttijd. Het gat tussen die twee zegt dus niets over engineering — het zegt iets over alles wat om engineering heen zit. Is dat gat groot, dan zijn de oorzaken meestal organisatorisch en niet technisch:

werk dat in de backlog blijft liggen omdat prioritering trager gaat dan levering
requirements die onvolledig binnenkomen, zodat de klok loopt voordat het werk kan beginnen
goedkeuringsketens die kalendertijd toevoegen zonder beslissingen toe te voegen
afhankelijkheden van de wachtrij van een ander team, waar jouw werk niet bovenaan staat
releasemomenten die afgerond werk vasthouden tot een geplande datum

Geen daarvan wordt opgelost door ontwikkelaars sneller te laten werken. Daarom kan een team twee kwartalen lang de cycle time verkorten zonder dat de business verschil merkt. Andersom gebeurt net zo goed: er wordt een stuk backlog leeggetrokken, de lead time daalt scherp, en aan de machine is niets veranderd.

Hoe DORA’s lead time for changes hierin past

Er is een derde tijdspanne die in deze gesprekken meegetrokken wordt en daar niet thuishoort. Lead time for changes, een van de vier DORA-metrics, loopt van commit tot draaiend in productie. Die begint later dan lead time in Kanban-zin: het verzoek, het wachten in de backlog en vaak het eerste deel van de ontwikkeling liggen al achter je op het moment dat de eerste commit landt.

De drie zijn dus genest, niet uitwisselbaar: lead time bevat cycle time, en lead time for changes overlapt het einde van allebei. Staat er in een rapportage "lead time" zonder dat erbij staat waar de klok start, dan valt het getal nergens mee te vergelijken.

Beide meten zonder ze te sturen

Allebei zijn ze eenvoudig te verbeteren door te schuiven met het startmoment, en dat is precies het risico waar je tegen moet ontwerpen. Meet je cycle time vanaf een statusverandering die iemand zelf zet, dan zakt het getal vanzelf zonder dat er sneller geleverd wordt. Een paar dingen houden het eerlijk:

leg start- en eindpunt één keer schriftelijk vast en gebruik die definitie over teams heen
haal de tijdstempels uit de bronsystemen — het issuesysteem en de deploymentpijplijn — en niet uit een handmatig gezette status
rapporteer de spreiding en niet alleen het gemiddelde: een mediaan met een lange staart is een ander probleem dan een traag midden
toon ze altijd samen, want elk van de twee is te verbeteren ten koste van de ander

Waar moet je naar kijken?

Kijk naar cycle time als de vraag over het team gaat: batchgrootte, reviewdruk, overdrachten, onderhanden werk. Kijk naar lead time als de vraag over de organisatie gaat: intake, prioritering, afhankelijkheden, releaseritme.

Het meest bruikbaar is het paar over tijd. Blijft cycle time stabiel terwijl lead time groeit, dan loopt werk vast voor of na het moment dat engineering het aanraakt, en geen enkele engineeringinspanning zal in het antwoord terugkomen. Alleen als ze samen dalen, betekent het wat mensen meestal bedoelen met "we zijn sneller geworden". Beide uit dezelfde bron halen, naast deployment frequency, maakt van een discussie over snelheid een vraag met een antwoord.