Estimating Work Without Lying to Stakeholders

Estimation is not prediction. It is a shared statement of uncertainty so product, design, and engineering can choose what to build next with eyes open. When estimates become promises, teams lie—quietly padding, silently cutting quality, or saying yes in the room and no in the sprint. When estimates stay honest, stakeholders may dislike the date, but they rarely feel betrayed.

This post is for ICs and tech leads who get asked “how long?” about features, migrations, and incidents—not for selling fixed-bid projects with imaginary precision. It connects to from tickets to outcomes, writing RFCs that unblock decisions when scope is still fuzzy, and shipping fast with a performance budget when “done” includes non-functional work.

Separate estimate, commitment, and target

Three different words; three different meanings:

• Estimate — Best guess given current information, often a range.
• Commitment — What the team agrees to try to hit with agreed scope and support.
• Target — What the business wants for a launch or contract.

Conflating them forces lies. Practice saying: “My estimate is two to four weeks for the integration; a commitment would require locking scope and removing parallel work.”

Microsoft’s guidance on agile planning treats backlog items as evolving; estimates update when learning happens—that is healthy, not failure.

Ranges beat single numbers

Single-point estimates imply false confidence. Prefer ranges with stated assumptions:

• “Three to five days if the API matches the doc; two weeks if we need a new auth flow.”
• “Unknown until we spike the legacy export format—two days for the spike, then re-estimate.”

Show confidence: “High confidence on UI; low on data migration until we sample production rows.” Stakeholders can then decide whether to fund the spike first.

The Planning Poker technique from agile practice helps teams align on relative size before converting to calendar time—useful when the bottleneck is unknown work, not typing speed.

Decompose until uncertainty is visible

Large estimates hide risk. Break work until items are reviewable in a PR or a day or two of focus:

• Vertical slices that demo user value.
• Explicit tasks for tests, docs, rollout, and monitoring.
• Dependencies on other teams called out with names, not “platform stuff.”

If every subtask is “medium,” you have not decomposed enough. Unknown buckets should be labeled discovery with a time box, not smeared across feature tasks.

Link decomposition to outcomes: “Estimate includes error UX and rollback, not only happy path”—aligned with owning product impact.

Assumptions belong in writing

Verbal estimates evaporate. Write assumptions in the ticket or planning doc:

• “Assumes one engineer, no PTO, existing CI.”
• “Assumes PM available for daily questions.”
• “Excludes legal review of new data processing.”

When assumptions break, re-estimate out loud early. That is not weakness; it is how trust compounds.

For cross-cutting work—auth, billing, background jobs and webhooks—list integration points you have not touched before. First-time work deserves wider ranges.

Historical data without fabricated stats

Teams improve estimates when they compare forecast to actual without gaming the numbers. You do not need a fancy dashboard to start:

• Tag completed work with “estimated vs actual” in retros.
• Note causes of overrun: scope creep, illness, dependency slip, unknown bug.

Avoid quoting industry “velocity multiples” unless they come from your team’s measured history. Generic “developers underestimate by 2x” anecdotes are not a plan.

Qualitative patterns are enough: “Migrations always take longer than UI because rollback drills eat a day.” That honesty helps PMs sequence work smarter.

Saying no without sabotage

When the asked date is impossible with current scope, options are:

1. Reduce scope to a credible MVP.
2. Add people or remove competing priorities (with real tradeoffs, not magic).
3. Move the date.
4. Spike to reduce unknowns, then renegotiate.

Saying yes when you mean no destroys morale and quality. Prefer “here is what fits in the window” with a ranked cut list.

Negotiation pairs with code review habits that raise the team: smaller batches make estimates more stable because review and deploy risk shrink.

Estimates for non-greenfield work

Brownfield systems punish optimism. Add explicit time for:

• Reading code nobody owns.
• Characterizing production behavior.
• Feature flags and gradual rollout.
• Observability and alerts before increasing traffic.

Cloud and cost-aware choices rarely appear in feature estimates until the bill arrives—call out infra review when estimates include new services or regions.

AI features need eval and safety time; treating them like a button swap is how products ship demos. Budget against evaluating AI product quality even when the model API looks “simple.”

Communicating upward

Executives often want one date. Give one date plus range and risk:

• “Target launch Oct 12; engineering range Oct 10–24 if billing integration surprises us; risk is third-party sandbox instability.”

Use the same doc in status updates so narrative does not drift. When you slip, explain what changed in assumptions, not only “we are late.”

Estimation and career trust

Senior IC credibility is built when your numbers age well—not when they are always low. Under-estimating to please the room burns you at promotion time when incidents trace to rushed work.

Public write-ups about how you plan—without leaking confidential roadmaps—feed public engineering brand as a senior IC. Teaching estimation in onboarding pays dividends when juniors stop treating “two weeks” as a meme.

Honest estimating is a leadership skill disguised as math. Ranges, assumptions, and early renegotiation keep stakeholders informed enough to choose—and teams honest enough to sleep at night.

Calibration rituals that stick

Short rituals beat annual planning theater:

• Weekly: compare forecast to done work; one sentence on why variance happened.
• Per epic: retrospective on estimate quality, not blame—was scope stable? dependencies honest?
• Quarterly: adjust team defaults (“we consistently underbudget QA”).

Atlassian’s story points and estimation guide reminds teams that points measure relative effort, not hours—useful when calendar time still depends on who is available and what is parallelized.

Fixed-date events without fantasy

Marketing launches and conference demos create fixed dates. Engineering response is not “work harder” but scope triage:

• Must-have for the date versus nice-to-have week after.
• Feature flags hiding incomplete flows.
• Explicit “won’t ship” list published to stakeholders.

Document what quality bar is relaxed temporarily—and schedule paydown. Shipping a broken checkout because the stage demo looked fine is how brands lose trust faster than missing a banner on the homepage.

Dependencies and vendor risk

Third-party APIs, design approvals, and legal review sit outside your keyboard. Estimates should list them with latest acceptable start dates: “Legal needs two weeks if we touch new PII; start review by Sept 1 or date slips.”

Vendor sandbox instability is a recurring surprise—widen ranges when integrating payments, email, or identity providers you have not used before. Pair with auth session patterns when estimates include security-sensitive flows you have not production-tested.

Individual skill: timeboxing spikes

When unknown dominates, propose a timeboxed spike with deliverables: document options, prototype throwaway code, list risks. Spikes are not free coding days—they end with a re-estimate and a recommendation, often feeding an RFC.

Senior ICs model stopping spikes when learning plateaus. Infinite research is another form of lying about when delivery can start.

Keep a personal log of estimates versus actuals for your own growth—not to punish yourself, but to see patterns in where you are optimistic. Share those patterns in planning meetings so the team benefits from your calibration, not only your output.