Treat an estimate as a forecast, not a promise. Give a range, confidence level, assumptions, and next checkpoint: "Based on the known scope, I expect 5–8 working days with medium confidence. That assumes the API is unchanged and design is final. I'll update the range after the integration test on Wednesday." If someone needs a fixed date, offer levers—scope, sequence, or capacity—instead of turning uncertainty into an unsupported commitment.
Someone asks, "How long will this take?" You have read half the ticket, the design is not final, and the third-party API has surprised you before. But silence feels incompetent, so you say, "Probably three days."
Three days later, that casual guess has transformed into a commitment everyone remembers except the assumptions you made when you gave it.
The way out is not refusing to estimate. Teams need forecasts to coordinate launches, staffing, sales, and support. The skill is communicating what the estimate means—and what could change it—without burying the answer under disclaimers.
Separate the Forecast, Target, and Commitment
These words answer different questions. A forecast describes what is likely given current evidence. A target is the outcome the organization wants. A commitment is a promise the team is prepared to organize around, usually after scope and risk have been examined.
Conflict starts when one person gives a forecast and another hears a commitment. Say which one you are discussing: "The requested target is May 15. Our current forecast for the full scope is May 20–27. We have not committed to a date yet."
This is not evasive language. It is the foundation for an honest planning conversation. Once everyone sees the gap, you can discuss scope, sequence, capacity, or risk instead of hoping the vocabulary will hide it.
Give Range + Confidence + Assumptions + Checkpoint
A decision-useful estimate has four parts. Range: the span supported by current evidence. Confidence: how likely you think that span is to hold, stated in plain terms such as low, medium, or high. Assumptions: the important conditions behind it. Checkpoint: when new evidence will let you confirm or revise it.
Try: "I expect the reporting change to take 6–9 working days with medium confidence. That assumes design signs off today and the analytics API supports the new grouping. I'll verify the API tomorrow and update the range by end of day."
Keep the assumption list short. Mention the ones that could materially change the forecast, not every ordinary uncertainty in software development.
Weak: "It should take about a week." Useful: "The current forecast is 5–8 working days, with medium confidence. That assumes no data migration and one review cycle. I'll narrow it after the schema spike on Tuesday."
Estimate the Known Work, Isolate the Unknown Work
When the uncertainty is too large, do not disguise discovery as implementation. Estimate a bounded investigation first: "I need one day to trace the legacy sync and test the vendor limit. After that I can estimate the change itself."
A useful spike ends with evidence or a decision, not "more research." Define the question, timebox, and output: a proof of concept, dependency map, benchmark, or options with updated ranges.
For larger work, break the estimate at meaningful boundaries: data model, backend behavior, client integration, migration, test and rollout. This exposes dependencies and allows progress to update the forecast. It also makes it harder for an entire hidden workstream—often migration or operational readiness—to disappear from the estimate.
When you need to explain those choices to someone outside engineering, connect them to outcomes using the same impact-first style as explaining what you do without boring everyone.
Scripts for Common Estimate Questions
Before discovery: "I can give you a responsible implementation estimate after a one-day spike. The unknown is whether the provider supports partial refunds; that answer changes the design."
Early planning: "Based on similar work, this is likely 2–3 weeks. Confidence is low until design and the data migration are clear. For roadmap planning, use three weeks and expect an update after discovery."
A small task with a dependency: "The code change is about a day, but release timing depends on app-store review. I can commit to submitting by Thursday, not to when the store approves it."
Parallel requests: "Each change is roughly three days, but the same engineer owns both. We can deliver A this week and B next week, or reverse them. Doing both by Friday is not supported by the current capacity."
An interruption-prone week: "The work is 4–6 focused days. Because I'm also primary on support this week, the calendar forecast is 7–10 working days."
When Someone Insists on One Date
Often the stakeholder is not demanding certainty; they need a date to put into another plan. Give them a planning point without hiding the risk.
Try: "For the planning sheet, use September 18. I would call that medium confidence, not a guarantee. September 25 is the high-confidence date if the full scope remains. I'll alert you by September 8 if the earlier date is no longer supported."
If the date truly cannot move, make the other levers explicit: "To commit to the 18th, we need to remove custom exports from the first release and freeze requirements on Friday. If full scope is required, I cannot responsibly commit to that date."
A deadline does not make uncertainty disappear. It changes what the team must adjust to achieve sufficient confidence.
Do not convert pressure into certainty. A date said more firmly is not a better estimate; it is only a harder surprise later.
Communicate a Changed Estimate Before It Becomes a Miss
Estimates should change when evidence changes. The professional failure is not revising a forecast; it is holding back the revision until the original date is already gone.
Use Change + Cause + New forecast + Options: "The import will not be ready Friday. Testing found that duplicate records can overwrite customer history, so we need a safe reconciliation step. The new forecast is Tuesday–Wednesday. We can keep Friday only by limiting the release to new accounts; I recommend moving the date because existing accounts are the main audience."
Avoid a long defense of why the old estimate was reasonable. Preserve the relevant learning, own any miss in process, and focus the conversation on the current decision. If giving an unwelcome update makes you freeze, the punchline-first approach in how to speak up at work helps: state the change before the history.
Avoid Padding, Heroics, and Fake Precision
Adding a secret 30 percent to every estimate does not teach the team which risks matter, and it eventually gets absorbed as expected speed. Use explicit contingency for named risks instead: "The migration is four days plus up to two days if data validation finds unmatched records."
Do not make overtime the hidden mechanism that turns a hopeful estimate into reality. If a date requires nights or weekends, that is capacity information leadership must see—not a personal debt you silently accept.
And avoid numbers more precise than the evidence. "6.5 days" is not inherently more rigorous than "about 1–2 weeks." Precision should come from well-understood, repeatable work, not from a detailed spreadsheet built on uncertain inputs.
Build a Calibration Loop
After delivery, compare the forecast with what happened. Which assumption failed? Which work was missing? Did interruptions change elapsed time? Was the range too narrow, or was the scope allowed to change without re-estimation?
Keep the review blameless and useful. The goal is not to reward people whose guesses happened to be right. It is to make the team's next forecast better by recognizing recurring sources of uncertainty.
Over time, your estimates become more credible because people can see how you update them—not because you claim to predict software work perfectly.
Reliability is not "my first date never changes." Reliability is "you will hear early when the evidence changes, understand why, and know what choices remain."
Your Action Step
Take the next estimate you are expected to give and write it in one sentence with four fields: range, confidence, assumptions, checkpoint. Then prepare the one lever you would offer if someone needs a faster, higher-confidence date.
That sentence may feel less satisfying than a crisp promise, but it gives everyone a much better basis for planning—and makes trust more likely to survive contact with reality. Rehearse the conversation with the Communication Trainer or browse more work communication guides.
Frequently Asked Questions
How do you give an estimate without committing to a deadline?
State that it is a forecast, then include a range, assumptions, confidence, and a review point. For example: 'My current estimate is 4–7 working days, assuming the schema is stable. Confidence is medium; I'll narrow the range after tomorrow's spike.'
What should I say when someone demands a single delivery date?
Give the planning date they need together with its confidence and consequence: 'June 14 is possible but low confidence with full scope. For high confidence, we need June 21 or we need to remove bulk export.' This turns pressure into an explicit decision about risk or scope.
When should a software estimate be updated?
Update it when evidence changes: a dependency slips, scope changes, an assumption fails, or completed work reveals a different pace. Do not wait for the original date to pass. Communicate the change, its cause, the new range, and available options as soon as the signal is credible.
How can developers improve estimate accuracy?
Break work into observable pieces, identify dependencies, compare with relevant completed work, and use short discovery tasks for major unknowns. Keep a record of estimate versus outcome so the team can calibrate. Accuracy improves through feedback, not through adding arbitrary padding to every number.
Tough talks
Practice the conversation you’ve been putting off
Rehearse this situation with a realistic AI partner, then get specific feedback on what worked and what to try next.
Preview the practice scenario →Simon H.
Simon is the founder of Communication for Nerds. A lifelong nerd, he learned social skills the way he learns everything else: by breaking them into systems, practicing small reps, and keeping what works. Every guide here is what he wishes someone had told him earlier. Read his story →
