Lead time vs cycle time when agents do the building
Stefan-Iulian Tesoi · · 6 min read
Lead time matters more, because a coding agent barely touches it. In the lead time vs cycle time split, cycle time runs from work started to work done and falls sharply once an agent builds. Lead time runs from request to delivery, and most of it is now the days an idea waits to be decided and specified.
Both clocks are worth keeping. They answer different questions, and the gap between them is where a team running agents finds its constraint.
Lead time vs cycle time: where does each clock start?
Lead time starts when someone asks for the work and stops when it reaches them; cycle time starts when work begins and stops when it is done. The difference between the two is the time the work spent waiting before anyone touched it.
What is cycle time, strictly? The Kanban Guide defines it as the elapsed time between when a work item started and when it finished, and leaves each team to decide what started and finished mean. That freedom is where most arguments about the number come from, so the definitions are worth writing down once.
| Clock | Starts | Stops | Whose wait it measures |
|---|---|---|---|
| Lead time | The item is requested | The change is accepted | The person who asked |
| Cycle time | Work on the item starts | The change is accepted | The team doing the work |
| Lead time for changes | Code is committed | The commit runs in production | The delivery pipeline |
Lead time for changes is the third clock, and the one most often confused with the first. DORA defines it as the time from a commit to that commit running in production. It starts after the code exists, so it says nothing about how long the idea waited to be decided.
Stop both of the first two clocks at acceptance, not at merge. A merged change that comes back as a fix a week later was not done, and a clock that stopped at the merge reports it as fast.
Why does cycle time fall while lead time stays flat?
Because a coding agent compresses the one stage it performs, building, and every other stage is still run by people at people's pace. Lead time contains all of those stages; cycle time contains mostly the one that shrank.
A build that took a developer three days takes an agent under an hour. The week the item spent waiting for someone to decide it was worth doing does not change at all. The two days it spent being specified may even grow, because an agent needs acceptance criteria a developer would have filled in from context. Review usually grows too, since the same reviewers now face more finished work.
So the lead time vs cycle time gap widens on the first day an agent is switched on. A team that reports cycle time alone sees a dramatic improvement. The person who asked for the feature sees almost none.
A falling cycle time next to a flat lead time is not a contradiction. It is a measurement of where the people are.
This is also why cycle time stops being a good proxy for delivery speed. It used to be most of the lead time, so improving one improved the other. Once building takes minutes, cycle time describes a small slice of the total, and the slice that is left is mostly review.
How do you split lead time into stages?
Record six timestamps on every item and subtract each from the next. That gives a lead time breakdown and a cycle time breakdown from the same data, with no second system to keep in sync.
- Requested: the item exists.
- Decided: someone agreed it will be done, and roughly when.
- Specified: the acceptance criteria are written well enough for an agent to start.
- Started: a coding agent or a person picked it up.
- Handed back: the build is finished and waiting for review.
- Accepted: the change was checked and closed.
Five intervals fall out: waiting for a decision, specifying, waiting to start, building, and review. Cycle time is the last three. Lead time is all five.
Most teams already have the timestamps, because a Kanban board records each column move. In Laimonade, the Ready column marks the specified stamp: work above it is still being decided or written, and work past it belongs to whoever builds it. A coding agent hands its work back to In Review, and no tool lets it move its own item further. Acceptance is then a person's decision, or Laimon's, with each closure stamped as Laimon's.
The first two intervals are the ones most dashboards leave out, and they are usually the largest. Measuring them is the first check in signs your team has a product ownership gap: when the time from prioritised to ready exceeds the build time, specification is the constraint.
Which stage should you shorten first?
The longest wait that a person controls, which is almost always one of the two before work starts. Shortening the build further buys little once it takes minutes.
- Waiting for a decision shrinks with a fixed triage slot. A weekly thirty-minute decision meeting turns an open-ended queue into one with a ceiling of seven days.
- Specifying shrinks when acceptance criteria are written at decision time, while the context is fresh, rather than when the item reaches the top of the queue.
- Review shrinks with a limit on how many items may sit in it at once. When the limit is reached, nobody starts new work until something is accepted.
The order matters. Speeding up review while decisions take three weeks moves the queue without shortening the lead time.
A lead time breakdown from one quarter
This breakdown is illustrative rather than a measured case, but its shape matches what teams running agents describe: a median and an 85th percentile for each stage, across one quarter of accepted items.
| Stage | Median | 85th percentile |
|---|---|---|
| Waiting for a decision | 6 days | 21 days |
| Specifying | 4 days | 9 days |
| Waiting to start | 0.5 days | 2 days |
| Building | 0.1 days | 0.5 days |
| Review | 1.5 days | 4 days |
Building is about 1% of the median lead time. Waiting for a decision is half of it, and its 85th percentile is three weeks. A team optimising its agent configuration is working on the smallest number in the table.
Stage medians do not add up to the median lead time, so report each column on its own rather than summing it. The agent-side numbers that sit beside this table, such as how often returned work is accepted without a fix, are covered in coding agent metrics worth tracking. The rest of the reporting stack is in engineering metrics that still work once agents build.
Frequently asked questions
Is DORA's lead time for changes the same as lead time?
No. DORA's lead time for changes starts when code is committed and stops when it runs in production, so it measures the delivery pipeline. Lead time in the Kanban sense starts when the work is requested. With coding agents the two diverge sharply: lead time for changes can be under a day while the item behind the commit waited weeks to be decided and specified.
Should cycle time include review?
Yes. Cycle time should stop when the change is accepted, and acceptance comes after review. Stopping the clock when the agent hands work back measures how fast code is produced, which is the stage that no longer limits anything. Review is where finished work now waits longest, so a cycle time without it hides the queue most likely to need a limit.
Should lead time be reported as an average or a percentile?
As a percentile, usually the 50th and the 85th. Lead time distributions have long tails: a few items wait months, and they drag an average far above what most requests experience. The median says what a typical request waits; the 85th percentile is the honest number to quote when someone asks how long a new request will take.