Estimating Work When Implementation Speed Is Unpredictable

Estimation was never good, and it worked well enough because errors were roughly consistent — a team that historically took twice its estimate kept taking twice its estimate. That consistency is what made velocity useful.

Agent-assisted implementation breaks the consistency, because the speedup is wildly uneven across task types. The mean comes down and the variance goes up, which is the worst combination for planning.

Why the variance rises

Pattern-following work compresses enormously. A CRUD endpoint matching an existing shape, a mechanical migration, tests against a clear contract — these can go several times faster.

Novel work compresses a little. An unusual approach, an unfamiliar system, a problem with no established shape.

Debugging hard problems barely compresses. Reproduction, localization, and understanding are still the work, and they're the hours that hurt.

Specification didn't compress at all, and it's now a larger share of elapsed time.

→ So two tasks that historically took a week can now take a day and four days respectively, and nothing in the ticket distinguishes them in advance.

What to estimate instead

Elapsed time to production, not implementation effort. This is the number people actually want and it always was — implementation effort was a proxy that used to correlate.

With a phase breakdown, because the phases now behave differently:

decided → specified      2-4 days   (gated on people's availability)
specified → implemented  0.5-2 days (compressed, variable)
implemented → reviewed   1-2 days   (bounded by review capacity)
reviewed → deployed      hours

⚠️ Note where the uncertainty concentrates. It's no longer mostly in implementation — it's in specification, which is gated on human availability, and in review, which is gated on capacity. Both are queue problems rather than effort problems, and queues are estimated differently.

The classification that helps

Before estimating, sort the work:

Pattern-following — an existing example to follow, complete specification, mechanical check available. Estimate low and with confidence.

Novel implementation — no clear precedent, approach needs designing. Estimate closer to historical, with wide bounds.

Investigation — the work is finding out what's wrong. ✅ Don't estimate; timebox. This was always true and it's more true now, because the temptation to assume the agent will find it quickly is strong and frequently wrong.

Specification-heavy — most of the work is deciding what should happen. Estimate the human availability, not the work.

That classification takes a minute per item and does more for estimate accuracy than any amount of refinement.

💡 What to stop doing

Story points. They were a proxy for effort, effort no longer maps to elapsed time, and re-calibrating them against a moving target produces numbers that mean nothing.

Velocity as a planning input. Historical throughput was useful when the ratio between estimate and actual was stable. It isn't.

Estimating investigation. Timebox it, then decide.

Treating the estimate as the commitment. With variance this high, a single number communicates false precision. Ranges, or better, a commitment about when you'll know more.

✅ What to do instead

• Track elapsed time and phase breakdown for everything, and use the actuals to calibrate rather than points.
• Classify before estimating.
• Estimate the queue, not the work, for specification and review — those are availability problems.
• Commit to checkpoints rather than completion dates for anything with investigation in it.
• Report the phase where time actually went, so the organization learns where its constraint is.

The takeaway

Estimation broke because the error stopped being consistent, not because it got worse. Estimate elapsed time to production with a phase breakdown, classify work by whether it's pattern-following, novel, investigation, or specification-heavy, and estimate queues rather than effort for the phases gated on people. Then track where time actually went — the phase breakdown is what tells the organization its real constraint, which is usually not the one everyone is optimizing.