Estimating Work When the Scope Is Fuzzy

Someone asks how long a piece of work will take, and it is only half defined. Refusing to answer is unhelpful. Giving a confident single number is worse, because it will be treated as a promise. There is a middle path.

Give a range, and say what drives it

Instead of “three weeks”, say “two to five weeks, and the reason for the spread is whether we can reuse the existing import code or have to write a new one”. Now the person asking knows the number is uncertain, knows why, and knows what would narrow it. A range with a reason is a useful input to a decision. A single number is a hostage.

Write down the assumptions

Every estimate rests on things you are taking for granted: the third-party API behaves as documented, the design is final, no data migration is needed, one developer is on it full time. List them. When one turns out to be wrong, the conversation is “assumption three did not hold” rather than “your estimate was bad”. The assumptions are half the value of the estimate.

Separate what you know from what you do not

Split the work into parts you have done before and parts you have not. The familiar parts you can estimate reasonably well. For the unfamiliar parts, do not guess a number. Time-box a short investigation, a day or two, to learn just enough, then estimate. Until that is done, state plainly that those parts are not covered by the number.

Estimate the whole job, not the coding

Coding is often less than half the elapsed time. There is review, addressing feedback, testing, fixing what testing finds, deploying, and the meeting where someone changes their mind. If your estimate covers only the first of these, it will be short by the same large margin every time. Estimate the path to merged and deployed, not to “it works on my machine”.

Re-estimate as you learn

An estimate is a snapshot with the information you had that day. A week in, you know more. Update the number and tell whoever is depending on it. A revised estimate delivered early is a normal part of the work. A wrong estimate defended to the end is a problem.

Track how you did

After the work ships, spend ten minutes comparing the estimate to reality. Not to assign blame, but to see the pattern. Most teams are consistently optimistic about integration and testing. Knowing your own bias is the cheapest way to get better.

Common questions

Why not just give a single number?

A single number for uncertain work is a guess dressed as a commitment. It sets up a conversation about why the guess was wrong. A range plus assumptions is more honest and more useful.

How do we handle the parts we do not understand yet?

Time-box a short spike to learn just enough to estimate them, and estimate the rest around it. Say clearly which parts the number does not cover.

Should the estimate include testing and review?

Yes. If your estimate is only coding time, it will be wrong by a predictable and large amount every time.