Estimating Work Without Faking Precision

The problem

Work estimation turns into a mess when the team tries to give a definitive answer for something that is still raw.

The conversation usually sounds like:

• “does this fit in the sprint?”
• “how many points do we give it?”
• “can we commit to Friday?”

And then the classic mistake appears:

taking poorly understood work and packaging it as if it were a reliable number.

Mental model

Think of it like this:

Estimating work is not predicting the future with more conviction. It is reducing the work until it fits into an honest reading.

In practice, that means doing three things before saying a number:

• cut scope
• separate discovery from execution
• make dependency and risk explicit

When that does not happen, the estimate looks objective, but it is only fragile.

Breaking the problem down

Work that is too big should not be estimated as one package

If the item still fits in phrases like:

• “improve onboarding”
• “refactor authentication”
• “close partner integration”

then it is still closer to a theme than to estimable work.

Before the number, it helps to split:

• what is alignment
• what is investigation
• what is implementation
• what is validation

Discovery should not look like predictable implementation

This is an error that sabotages sprints all the time.

Some parts of the work are familiar to the team.

Some parts depend on discovering:

• legacy behavior
• a third-party response
• a rule that is still not closed
• a bottleneck that is still not reproduced

If all of that turns into “three days,” the problem is not the number. It is the mixture.

A range is often better than a hard commitment

In many contexts, the better answer is:

• “the part we control fits into one or two days”
• “if the dependency responds well, we close it in this sprint”
• “the base scenario fits; the risk is concentrated here”

That does not weaken the answer.

It makes the answer more useful.

A good estimate needs to fit the team’s ritual

In planning, the estimate is not there to make you sound sophisticated.

It is there to help the team decide:

• what goes in
• what stays out
• what needs to be split first
• where the risk is concentrated

When the conversation turns into defending a number, the ritual already started wrong.

Simple example

Imagine a task:

add multiple coupons in checkout.

Weak answer:

• “I think this is about two days”

Better answer:

• business rule: still needs to be closed with product
• backend calculation: the team knows this part
• receipt and analytics effect: needs validation
• biggest risk: cumulative coupons breaking existing discounts

Then the estimate becomes less fantasy-driven:

If the rule closes without new exceptions, the known implementation fits in two days. If discovery enters the calculation or promotional exceptions, the item needs to be cut because it stops being predictable work.

Common mistakes

• Estimating a vague theme instead of split work.
• Treating investigation as if it were predictable execution.
• Using one single number to look more confident.
• Hiding dependency inside the estimate.
• Leaving planning with a feeling of precision and no clarity about hypotheses.

How a senior thinks

Someone more mature tries to protect the team’s operational honesty.

So the conversation gets closer to:

• what is already understood enough to come in
• what still needs framing
• which part is a bet
• what needs to be split into a spike, a phase, or a smaller item

That reduces frustration because it avoids promising as solid something that is still soft.

What the interviewer wants to see

When this theme comes up in interviews, the evaluator usually looks for:

• ability to break work down
• awareness of risk and dependency
• honesty about uncertainty
• criteria for turning ambiguity into a plan

A strong answer usually sounds like this:

I try not to estimate amorphous packages. First I separate what is known work, what is discovery, and what depends on a third party. If it is still too large, I cut it before I say a number. When it makes sense, I prefer a range or a scenario with explicit assumptions instead of a hard commitment that only sounds safe in the meeting.

A useful estimate is not the one that looks most exact. It is the one that helps the team decide better what fits now.