Choose the most accurate and professional way to give time estimates, revise them, and set expectations — in 5 realistic scenarios.
Time estimation — 5 key phrases
"This should take about [X days/hours] — I'll confirm after a short spike."
"I estimate 2-3 days — assuming no blockers on the integration side."
"I'm 80% done — the remaining work is [specific items]. On track for [date]."
"By end of sprint — which means close of business [day of week]."
"My revised estimate is [date] — I'm flagging this early so we can re-plan if needed."
0 / 5 completed
1 / 5
Your team lead asks how long the new feature will take to implement. You genuinely don't know yet. Which response is most professional?
A spike + time-boxed estimate is the professional response to genuine uncertainty. "Spike" means a short investigation (usually 1-4 hours) to understand scope before committing to an estimate. "Give you a number by EOD today" turns uncertainty into a commitment with a deadline. Compare: "It'll take about a week" stated without investigation is a guess that might be wildly wrong. "It depends" with no follow-up is unhelpful — you're not moving the conversation forward. Uncertainty is fine; unmanaged uncertainty is not.
2 / 5
You estimated a task at 2 days but you're realising it will take 4-5 days. How do you communicate this as soon as you know?
Re-estimate early, explain the cause, offer the team a chance to re-plan. "After discovering the existing API has no test coverage" is specific — the team can verify and possibly help. "4-5 days" is a concrete revised range. "Adjust the sprint scope" shows you're thinking about team impact, not just your own task. Raising this early (as soon as you know) is critical — raising it on the last day of the sprint is too late to take any action. The cost of early transparency is low; the cost of late transparency is high.
3 / 5
A product manager asks: 'When can we show this to the client?' You're 50% done. Which answer sets appropriate expectations?
Give a range with conditions — and commit to a firm date soon. "50% done" sets the baseline. "Demo-ready by Thursday" is the optimistic case. "Friday is more realistic if [risk]" acknowledges uncertainty without creating panic. "I'll give you a firm date by EOD tomorrow" — this is the key phrase. It moves the conversation from uncertainty to a commitment with a specific follow-up. Product managers need dates for client communication — your job is to give a credible estimate with named risks, not perfect certainty.
4 / 5
How do you say you are 80% done with a task and expect to finish within the current sprint?
Quantify + itemise remaining work + confirm sprint commitment. "80% through the search indexing feature" is more credible than "almost done" — it gives a specific number. "The remaining work is writing integration tests and updating the documentation" — itemising what's left shows you know exactly what you have left, not just a vague sense of completion. "On track to finish by end of sprint" is the clean commitment. This level of detail takes 10 extra seconds to say but dramatically increases your credibility as an estimator.
5 / 5
Someone asks 'By end of sprint' — but the sprint ends Friday and today is Wednesday. How do you clarify professionally?
Translate sprint jargon into calendar dates when precision matters. "By close of business Friday" removes any ambiguity. "So you'll have it for Monday's demo" shows you're thinking from the product manager's perspective — they care about the demo, not the sprint boundary. This is a key professional skill: translating internal technical terminology (sprint, EOD, EOW) into concrete calendar terms for non-technical stakeholders. "End of sprint" without a date is ambiguous to anyone outside the development team.