Time Estimates

Option C — a range estimate with a named assumption and a commitment to a better estimate after scoping.

Structure of a professional rough estimate:

[Range] + [key assumption] + [qualifier/commitment to refine]

Example: "1–2 weeks, assuming the OAuth integration is straightforward — I can give a firmer number after I've reviewed the spec."

Why this works:
• Provides a number the PM can use for planning (not a refusal)
• The range (1–2 weeks) communicates uncertainty better than a single number
• The assumption ("assuming OAuth is straightforward") tells the PM what to watch for
• The commitment ("firmer number after review") is professional — not a blank cheque

Common estimation hedging phrases:
• "rough estimate" — signal this is not a commitment
• "in the ballpark of" — informal; conveys approximation
• "assuming [X]" — names the key dependency
• "I'd want to caveat that with" — introduces uncertainty
• "I can give you a number, but hold it loosely" — informal, honest
• "I'll have a better number for you after [X]" — commits to a refined estimate

Avoid: single-number answers without caveats ("two weeks") — they become commitments regardless of your intent.

Option B — a specific estimate with an explicit assumption and a named contingency.

Conditional qualifier structure:

[Estimate] assuming [specific condition]. If [risk scenario], [add/subtract/adjust].

This structure is valuable because:
1. It shows you have thought about risks, not just the happy path
2. It gives the PM/lead the information to decide which conditions to watch
3. If the contingency occurs, you can point to the original estimate — no surprises

Common conditional phrases:
• "assuming [X] holds" — "assuming the API is stable"
• "provided that [X]" — "provided no new requirements come in"
• "as long as [X]" — "as long as we don't hit AWS limits"
• "if [risk], add [N days/hours]" — explicit risk buffer
• "barring any surprises" — informal, acknowledges unknowns
• "in the best case / worst case" — 3-point estimation language

Three-point estimate format (more formal):
• Best case: 2 days (everything goes smoothly)
• Most likely: 3.5 days
• Worst case: 5 days (if the third-party sandbox is unstable)

Hedge words like "definitely" (Option A) introduce overconfidence — use them only when you have very high certainty about a scoped, well-understood task.

Option B — a revised estimate with the specific reason for the change and proactive flagging to allow scope adjustment.

Revised estimate structure:

"I need to revise my estimate for [task/feature].
New estimate: [new number] rather than [original estimate].
Reason: [specific cause of the change].
[Proactive offer]: I'm flagging this now so we can [adjust/descope/reprioritise]."

Why this is professional:
• "I need to revise my estimate" — takes ownership without blame
• New + original: "6 days rather than 3" — explicit; stakeholders can see the change
• Specific reason: "edge cases around partial refunds on split orders" — shows you understand what changed, not just that it's hard
• Proactive flag: "flagging now to give us time to adjust" — the most professional element; early warning is far more valuable than a last-minute miss

Key phrases for estimate revisions:
• "I need to revise my estimate" — direct, clear
• "I'm revising upward / downward" — directional language
• "This is taking longer than expected because" — opener with reason
• "I'm flagging this early so we can" — proactive language
• "I didn't anticipate [X] when I gave the original estimate" — honest, non-defensive

Note: revising estimates is normal and professional. The only error is not flagging early.

Option C — references a past comparison, breaks down the estimate by phase, and gives a summary figure.

Why comparison-based estimates are more credible:
• "Based on a similar migration in Q3" — demonstrates this is informed, not a guess
• Breaking into phases (implementation / testing / review) shows you understand what's involved
• "4–5 hours + 1–2 hours = ~6–7 hours" → "call it a day" — explicit arithmetic, rounded up

Estimation phrases for tasks you've done before:
• "Based on similar work in [project/sprint], I'd estimate…"
• "We did something comparable last quarter — that took X, so similar scope here"
• "Roughly same as the [Y] task, which was about Z"
• "I've done this type of migration before — typically [X] hours"

Breaking down by phase (standard practice):
• Implementation: [X]
• Testing: [X]
• Code review / PR cycles: [X]
• Buffer for unknowns (10–20%): [X]
• Total: [sum]

"Should be quick" (Option A) invites scope expansion and creates a false expectation — avoid vague time words without numbers.

Option C — confirms it's possible with explicit tradeoffs named, and offers an alternative timeline for the full scope.

The quality/scope/time tradeoff conversation:
When any two of these are fixed, the third must flex:
• Quality ↓ + Scope ↓ = Friday — "achievable if we deprioritise test coverage and skip edge cases"
• Quality ↓ + Scope ↑ = impossible
• Quality ↑ + Scope ↑ = next week — "early next week is safer if you need full quality"

Why this is the right approach:
• Never say yes when you mean "yes, but only if we cut corners"
• Make the tradeoffs visible — the PM/lead decides which tradeoff to accept
• "I'd want to log those as tech debt" — professional; shows consequences are tracked, not hidden
• Offering an alternative ("early next week") gives the stakeholder a real choice

Phrases for deadline pressure responses:
• "That's achievable if we scope down to [X] — but [Y] would be cut"
• "I can do X by Friday, but Y would need to wait until next week"
• "If Friday is a hard constraint, we could ship without [feature] and follow up"
• "Friday is aggressive — what's the cost of missing it?" — sometimes the best move is to clarify urgency

"I'll try my best" (Option D) is unprofessional — it gives no information and sets up a surprise.

Option C — frames the estimate explicitly as order-of-magnitude, names the assumptions, and disclaims precision explicitly.

Key phrase: "rough order of magnitude" (ROM)
In engineering, this phrase signals that an estimate has a tolerance of ±50–100% and should not be used for planning without refinement.

When a rough estimate is requested:
• Give a number — refusing is unhelpful and unprofessional
• Frame it explicitly: "off the top of my head" / "rough order of magnitude" / "ballpark only"
• Name the key assumptions: team size, scope exclusions, dependencies
• Explicitly disclaim precision: "don't hold me to that until we scope it properly"

ROM estimate phrases:
• "Rough order of magnitude: [X]" — signals ±50–100% tolerance
• "Ballpark: [X]" — informal, same signal
• "Order of magnitude: [X]" — ×10 precision only
• "My gut says [X], but stress-test that with a proper scoping session"
• "I'd budget [X] as a placeholder — we'll firm this up after discovery"

Estimation maturity levels:
• ROM: ±50–100% (before scoping)
• Budget estimate: ±25–50% (after high-level scoping)
• Definitive estimate: ±10% (after detailed scoping and spike tickets)