A software estimate can become a promise in the listener's mind long before an engineer intends to make one.
"It should take about three days."
That sentence sounds simple, but it leaves important questions unanswered. Does three days include testing and review? Has the engineer inspected the integration? What could change the estimate? Is anyone authorized to treat it as a delivery commitment?
The solution is not to add vague protection such as maybe or hopefully. A useful estimate communicates four things:
Range and unit → assumptions → confidence → checkpoint
Estimate without promising
A useful estimate exposes the evidence and the uncertainty.
Ready to go beyond the quiz on "Tentative"?
Take the full learning path: hear it in real workplace contexts, watch short explanations, learn its nuances and when to use it, then practice using it yourself.
Start learning for free →Now see if you can use it naturally yourself.
Try it yourself
You know how to use "Tentative," too.
Keep going with the full learning path — more workplace contexts, related expressions, and continued practice.
Continue with "Tentative" →There's more to "Tentative" than it seems.
You've got part of it, but the full learning path goes deeper into its nuances, workplace contexts, and when it sounds natural — then gives you practice using it yourself.
Learn "Tentative" in depth →1. Give a range and name the unit
Use a narrow range only when the work is understood well enough to support one.
Too definite:
"It will take three days."
More accurate:
"My current estimate is three to five engineering days."
An engineering day describes effort, not necessarily one elapsed calendar day. Three engineering days could finish on Wednesday or next week depending on when the work starts, the engineer's availability, review time, and deployment steps. If the listener is asking about a delivery date, connect effort to the actual plan—or say that the date cannot be inferred yet.
"I estimate three to five engineering days of effort. With one engineer starting Tuesday and one additional day for review and deployment, the current delivery range is Friday through the following Tuesday."
Useful patterns include:
- "My current estimate is..."
- "At this stage, I would estimate..."
- "The tentative range is..."
- "This is a rough estimate, not a committed date."
Tentative means not final or settled and therefore still subject to change. It does not mean careless. Explain what evidence or decision would make the estimate firmer.
2. State the assumptions
An estimate is easier to evaluate when its assumptions are visible.
"My current estimate is three to five engineering days, including implementation and tests but not review or deployment, assuming the API contract stays unchanged and the test environment is available."
This is not defensive language. It tells the listener which conditions the estimate depends on. If a condition changes, the team can update the estimate without pretending the original one covered different work.
Do not list every imaginable uncertainty. Name the assumptions that could materially change timing, scope, or risk.
Want to actually use "Tentative" naturally at work?
Understanding it is one thing. Practice its nuances, see how it works in real workplace situations, and use it yourself with feedback.
Start the "Tentative" learning path →3. Calibrate confidence
Confidence should describe the quality of the evidence, not the engineer's personality.
Less useful:
"I'm not very confident."
More useful:
"Confidence is moderate because we have implemented the main path, but we have not tested the migration against production-scale data."
Natural phrases include:
- "I have high confidence in the implementation estimate, but lower confidence in the integration work."
- "The range is still tentative because we have not inspected the legacy data."
- "I can give you a firmer estimate after the spike."
Avoid fake precision. Saying "four days" instead of "three to five" does not make the underlying uncertainty disappear.
4. Name the next checkpoint
An uncertain estimate becomes actionable when the listener knows when it will be reviewed.
"I can confirm or revise the range after tomorrow's integration test."
"Let me complete the technical spike this afternoon, and I will return with a firmer estimate before planning."
A checkpoint is not permission to avoid an answer. Give the best supported estimate you have now, then explain what evidence will improve it.
Estimate, proposal, and commitment are different
An estimate predicts effort or duration from current evidence. A proposal recommends a plan. A commitment is a promise the responsible person or team is prepared to be accountable for.
"I estimate three to five engineering days of effort" does not automatically mean "I commit to Friday."
If a stakeholder asks for a commitment too early, keep the distinction explicit:
"I can give you a tentative estimate today. I would not commit to Friday until we have tested the integration."
That is clearer than quietly adding buffer or agreeing and hoping the unknowns disappear.
A realistic planning dialogue
Product manager: Can we tell the client this will be ready Friday?
Software engineer: My current estimate is three to five engineering days, including implementation and tests but not review or deployment. I can start Tuesday. Confidence is moderate because we have not run the vendor integration yet.
Product manager: So is Friday possible?
Software engineer: Friday is possible only at the three-day lower bound, with review and deployment compressed into the remaining day. I cannot support it as a commitment until we run tomorrow's integration test. After that, I can confirm the effort range and propose a delivery date.
Product manager: Then let's hold the client date until after the test and include review and deployment in the proposal.
The engineer answers the question without turning incomplete evidence into certainty.
Common mistakes
Hiding uncertainty behind “should”
"It should be done by Friday."
Should can sound like a prediction, expectation, or promise. Name the evidence instead:
"Friday is the working estimate, assuming the schema review does not require changes."
Giving only a disclaimer
"No promises, but maybe next week."
This protects the speaker but does not help planning. Give a range, the major assumption, and a checkpoint.
Calling every estimate tentative forever
As uncertainty falls, update the language. A perpetual rough estimate can sound evasive. Say what has been confirmed and what remains open.
Quick scenario challenge
You have reviewed the main service, but a third-party authentication flow remains untested. Which update is strongest?
A. "It should definitely take four days."
B. "Maybe four days, but I don't want to promise anything."
C. "My current estimate is four to six days, assuming the authentication flow matches the documentation. Confidence is moderate until we test it tomorrow; I can firm up the range after that."
Answer: C. It gives a usable range, identifies the important assumption, calibrates confidence, and names the next checkpoint.
Return to English for Software Engineers for more language for planning, deadlines, reviews, and technical decisions.
Related guides
- Tentative in a Sentence
- What Does Ballpark Estimate Mean at Work?
- How Software Engineers Can Push Back on an Unrealistic Deadline
Calibrate an engineering estimate
Lyra Practice helps advanced non-native English professionals learn the nuance of high-value workplace expressions and practice using them in realistic scenarios, so their English sounds natural, precise, and senior at work. Try Lyra Practice.