Status Droid how long software work actually takes

Cycle Time and What It Hides

Two metrics survive from before all this and are still worth having.

Lead time is how long from a request arriving to it being delivered. The client's experience. For a practical implementation reference alongside the measurement argument here, see this reference.

Cycle time is how long from starting work to finishing it. Your experience.

The gap between them is queue — work sitting untouched. For most small teams the queue is larger than the work, which is why lead time is the number a client cares about and cycle time is the number a developer defends.

Both have become misleading in the same specific way. Stanford hosts ongoing work on measuring software-engineering productivity See Stanford Software Engineering Productivity.

Why both got faster without delivery improving

Cycle time measures from start to "done." If "done" means merged, and review has moved downstream or been compressed, cycle time drops while the work is not finished — it has been relocated. Throughput measured before verification is a loan.

Both are sensitive to task size, and assisted work encourages larger changes because generating them is easy. A large change with a long review looks, in the data, like one slow item rather than the several fast items it replaced. Or the opposite: split it and cycle time looks excellent while lead time does not move at all.

Neither counts rework. A task that ships in two days and returns in three weeks as a defect records a two-day cycle time. The correction becomes a new item with its own healthy metric.

So a team can improve both while delivering the same or less. Not by cheating — by generating faster, reviewing lighter, and paying later.

What to add so they mean something

Three additions, each cheap.

Count rework as belonging to the original item. Not a new ticket with its own clean cycle time. If a task comes back, its real cycle time includes the return. This single change makes the metric honest and it is the one nobody makes because it makes the numbers worse.

Record where the time went, at the coarse level of production versus verification versus waiting. Two of those three are what changed.

Track item size. Cycle time without size is uninterpretable — a falling cycle time with falling item size is not an improvement, it is a change of unit.

The third number, which matters more

Time to correct.

From "we discovered this is wrong" to "it is fixed and verified." Almost nobody measures it, and it is the number that decides how much verification you can safely skip.

If correcting takes an hour, you can move fast and fix things, and lighter review is a rational trade. If correcting takes a week — because it needs a release, a migration, a customer conversation — then verification is not overhead, it is the cheapest part of the process, and skipping it is borrowing at a bad rate.

Most teams have never measured this, which means they are making the speed-versus-care trade without knowing the exchange rate. It is also the number that tells you whether an estimate can safely be aggressive.

What DORA-style metrics do and do not give a small team

Deployment frequency, lead time for changes, change failure rate, time to restore. Designed for organisations with enough volume for the numbers to be stable.

On a two-person team they are mostly noise. Four deployments a month means change failure rate moves in 25% increments. Any trend you see is one bad week.

What survives at small scale is the pair that does not need volume: change failure rate over a long window, and time to restore. Both answer the question that matters — how expensive is it when we are wrong — and both are usable with a dozen data points.

What does not survive is deployment frequency as a goal. It is a proxy for batch size, and at small scale you can just look at batch size.

The honest use of all of this

None of these numbers tells you whether the team is doing well. They tell you where time is going and how expensive mistakes are, which are the two inputs you need for estimating and pricing.

The moment they become targets, they stop describing anything — the same failure as any tracking used to judge people rather than to plan work. Cycle time in particular is trivially gamed by splitting items, and the gaming is usually unconscious.

The short version