Giving an Estimate

  • My estimate is [X–Y days] — I'm treating the higher end as the more likely.
    Giving a range with a lean toward the upper bound
    "My estimate is 3–5 days — I'm treating 5 days as the more likely given the unknowns."
  • That's a rough order of magnitude — probably [X], could be 2× if we hit unknowns.
    Signalling a high-level estimate with uncertainty
    "That's a rough order of magnitude — probably 2 weeks, could be 4 if the third-party API is as undocumented as I've heard."
  • I can give you a more accurate estimate after I do a short spike — maybe 2 hours to investigate.
    Proposing a spike before committing to a number
    "I'd rather not guess on this one — I can give you a better estimate after a 2-hour spike to understand the scope."
  • The estimate assumes [condition] — if that changes, the timeline changes too.
    Making estimate assumptions explicit
    "The estimate assumes the design is finalised. If specs change after we start, the timeline will be impacted."

Updating Estimates

  • I need to revise my estimate — the original assumption turned out to be incorrect.
    Professional estimate revision
    "I need to revise my estimate — the auth service integration is significantly more complex than I expected based on the documentation."
  • We're tracking to [X] — here's an updated breakdown.
    Proactive progress update with revised breakdown
    "We're tracking to 8 days, not 5 — here's an updated breakdown of where the extra time is going."
  • Confidence level: [high/medium/low] — [reason].
    Explicitly signalling estimate confidence
    "Confidence level: medium — I've done similar integrations before, but this vendor's API has unusual rate limits."

Phrases to Avoid

These common phrasings undermine your professionalism. Here are better alternatives.

Avoid "I'll be done when it's done."
Better "I can give you an estimate after a short investigation — say, by end of day tomorrow."

"When it's done" is unhelpful for planning. Even a rough estimate with a caveat is more valuable than no estimate.

Avoid "It should only take a day."
Better "My best estimate is 1–2 days, assuming no integration surprises."

"Should only" is over-optimistic phrasing. A range with an explicit assumption is more honest and defensible.

Avoid "I can't estimate this."
Better "There are too many unknowns to estimate accurately right now — I'd propose a time-boxed spike first."

"I can't estimate" is a conversation stopper. Proposing a spike to reduce uncertainty is a constructive alternative.

Practice Exercises

Choose the most professional or correct phrase for each scenario.

Frequently Asked Questions

What is the difference between an estimate and a commitment?

An estimate is your best prediction with stated uncertainty. A commitment is a promise. Treat them differently — estimates should be honest, commitments should be achievable.

What is "Hofstadter's Law"?

Hofstadter's Law states: "It always takes longer than you expect, even when you take Hofstadter's Law into account." It's a humorous acknowledgement that software estimation is systematically optimistic.

What is "planning poker"?

Planning poker is a group estimation technique where each team member privately selects a story point card and reveals simultaneously. Outliers discuss their reasoning to reach consensus.