Status Droid how long software work actually takes

Estimating Assisted Work

You cannot estimate assisted work by estimating the work and adjusting for the assistant. The adjustment is not a percentage, it is a different shape depending on the task, and applying an average to a bimodal distribution produces a number that describes nothing.

What follows is a method that survives that. It takes about five minutes per task and it is defensible in front of a client. When this estimation problem needs an operational counterpart, self-reporting bias offers a useful reference point.

Step one: classify before you estimate

Two questions, thirty seconds. The same two that decide whether an assistant helps at all.

Would I know quickly if the output were wrong?

If it were wrong, who pays?

That places the task in one of three buckets. Agile Alliance provides background and practitioner material on agile estimation and planning See Agile Alliance.

Generation-heavy. Cheap to verify, low consequence. Boilerplate, scaffolding, a specified transformation, a throwaway script. Expect a large speedup and estimate accordingly.

Integration-heavy. Moderate to verify, moderate consequence. Fitting something into an existing system, a feature in a codebase you know. Expect a modest change in either direction.

Verification-heavy. Expensive to verify, real consequence. Auth, payments, permissions, migrations, anything in a mature codebase with implicit standards. Expect no speedup, and budget for the possibility of a slowdown.

Do this before you think about hours. If you estimate first and classify afterwards, the number anchors you and the classification becomes a rationalisation.

Step two: estimate the halves separately

For every task, two numbers.

Producing it. How long to get something that runs.

Establishing it is right. Reading it, testing it, fixing what came back, satisfying whatever standards apply.

Estimating these together is the most common failure in assisted work, because the first half is the part that shrank and the part your intuition is anchored on. You produce a number that describes the cheap half and quietly assumes the expensive half is proportional to it. It is not — the ratio between them is exactly what changed.

Rough starting ratios, to be replaced by your own within two months:

Bucket Producing Verifying
Generation-heavy 20% 80%
Integration-heavy 40% 60%
Verification-heavy 25% 75%

Those look surprising until you notice the totals differ. In generation-heavy work the whole task is small, so 80% of a small number is still small. In verification-heavy work the total is large and unchanged.

Treat those figures as a placeholder, not a finding. They are a reasonable starting shape, not measured constants, and the point of tracking is to replace them.

Step three: give a range, and mean it

If your spread widened, your estimates should have widened. A single number is now a claim you cannot support.

Generation-heavy: narrow range. You will usually be right.

Integration-heavy: moderate range, perhaps 1.5x from low to high.

Verification-heavy: wide range, 2x or more, and say why. This one touches permissions, so most of the cost is being sure rather than writing, and being sure is what varies.

Clients accept wide ranges on hard work far more readily than people expect, provided the reason is specific. What they reject is a wide range with no explanation, which reads as not knowing.

Step four: name the trigger for re-estimating

Decide in advance what would change the number, and say it when you give the estimate.

If the existing auth code turns out to be undocumented, this moves from the middle of the range to the top.

This is the highest-value sentence in the whole process. It converts a later re-estimate from bad news into a thing you predicted, which is the difference between losing trust and building it.

What to do when you have no data yet

Everyone starts here.

Use your pre-2024 instinct for the verification half, unadjusted. That part of the work has changed least, and your old intuition is closest to calibrated there.

Discount the production half aggressively for generation-heavy work only. Half or less of what it used to be.

Do not discount anything for verification-heavy work. If anything, add.

Then record actuals against estimates for fifteen tasks and stop guessing.

The check that catches the common error

Before sending an estimate, ask: which half of this number is verification?

If the answer is "less than half" on anything with real consequences, you have estimated the writing and forgotten the checking. That is the single most frequent way assisted work runs over, and it takes ten seconds to catch.

The short version