6 exercises — give ranges, qualify uncertainty, name assumptions, and communicate revised estimates professionally.
0 / 19 completed
1 / 19
A product manager asks: "How long will the new user authentication feature take?" You have not seen the full spec. Which response is most professional?
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.
2 / 19
Which of these correctly uses a conditional qualifier in an estimate?
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.
3 / 19
Halfway through the sprint, you realize a task will take twice as long as estimated. How do you communicate a revised estimate?
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.
4 / 19
You are asked to estimate a task you have done before. Which estimate phrasing shows the highest precision?
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.
5 / 19
You are under pressure to commit to "by Friday". You think it's possible but risky. Which response is most appropriate?
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.
6 / 19
A senior engineer asks you to estimate "just off the top of your head" how long a full system migration will take. Which is best?
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"
During a code review of a new API endpoint for user profiles, Sarah (the junior developer) provides an initial estimate of 4 hours to implement and test. Mark (the senior engineer) responds with: "That sounds reasonable, but let's factor in the potential need to handle edge cases around international character sets – we've seen that cause unexpected slowdowns before." Which of the following is the *most* helpful follow-up from you as a reviewer?
The best response acknowledges Mark's concern while still guiding Sarah towards a more detailed estimation process. Simply accepting the initial estimate without further questioning misses an opportunity to surface potential issues. Option 3 is too dismissive; option 1 ignores crucial risk assessment. Option 2 lacks practical guidance – it simply asks for more information without suggesting action. Option 4 proposes a structured approach, which is what's needed in this scenario.
8 / 19
Mark (the senior engineer) responded with: "That sounds reasonable, but let's factor in the potential need to handle edge cases around international character sets – we've seen that cause unexpected slowdowns before." Which of the following is the *most* helpful follow-up from you as a reviewer?
A) "Okay, I'll add 8 hours to the estimate. International character sets are always tricky!"
B) "That's a good point. Could you elaborate on what specific edge cases you anticipate? Perhaps we can break this down into smaller tasks and estimate each individually."
C) "Four hours is ambitious for that scope. Let's just stick with the original estimate – we don't have time to over-engineer it."
D) "Thanks for flagging that! I'll update the task description to include 'international character set support' and add a note about potential performance impacts."
The best response (B) demonstrates proactive investigation and collaborative risk assessment. It acknowledges Mark's concern, seeks clarification on the specific unknowns, and proposes a more granular approach to estimation – crucial for realistic development planning. Options A and C are overly simplistic or dismissive of potential challenges; D is a passive acknowledgement without actively seeking information. This aligns with best practices in dev-workplace communication.
9 / 19
During a code review of a new API endpoint for user profiles, Sarah (the junior developer) provides an initial estimate of 4 hours to implement and test. Mark (the senior engineer) responds with: "That sounds reasonable, but let's factor in the potential need to handle edge cases around international character sets – we've seen that cause unexpected slowdowns before." Which of the following is the *most* helpful follow-up from you as a reviewer?
The best response acknowledges Mark's concern while still guiding Sarah towards a more detailed estimation process. Simply accepting the initial estimate without further questioning misses an opportunity to surface potential issues. Option 3 is too dismissive; option 1 ignores crucial risk assessment. Option 2 lacks practical guidance – it simply asks for more information without suggesting action. Option 4 proposes a structured approach, which is what's needed in this scenario.
10 / 19
Mark (the senior engineer) responded with: "That sounds reasonable, but let's factor in the potential need to handle edge cases around international character sets – we've seen that cause unexpected slowdowns before." Which of the following is the *most* helpful follow-up from you as a reviewer?
A) "Okay, I'll add 8 hours to the estimate. International character sets are always tricky!"
B) "That's a good point. Could you elaborate on what specific edge cases you anticipate? Perhaps we can break this down into smaller tasks and estimate each individually."
C) "Four hours is ambitious for that scope. Let's just stick with the original estimate – we don't have time to over-engineer it."
D) "Thanks for flagging that! I'll update the task description to include 'international character set support' and add a note about potential performance impacts."
The best response (B) demonstrates proactive investigation and collaborative risk assessment. It acknowledges Mark's concern, seeks clarification on the specific unknowns, and proposes a more granular approach to estimation – crucial for realistic development planning. Options A and C are overly simplistic or dismissive of potential challenges; D is a passive acknowledgement without actively seeking information. This aligns with best practices in dev-workplace communication.
11 / 19
During a code review of a new API endpoint for user profiles, Sarah (the junior developer) provides an initial estimate of 4 hours to implement and test. Mark (the senior engineer) responds with: "That sounds reasonable, but let's factor in the potential need to handle edge cases around international character sets – we've seen that cause unexpected slowdowns before." Which of the following is the *most* helpful follow-up from you as a reviewer?
The best response acknowledges Mark's concern while still guiding Sarah towards a more detailed estimation process. Simply accepting the initial estimate without further questioning misses an opportunity to surface potential issues. Option 3 is too dismissive; option 1 ignores crucial risk assessment. Option 2 lacks practical guidance – it simply asks for more information without suggesting action. Option 4 proposes a structured approach, which is what's needed in this scenario.
12 / 19
Mark (the senior engineer) responded with: "That sounds reasonable, but let's factor in the potential need to handle edge cases around international character sets – we've seen that cause unexpected slowdowns before." Which of the following is the *most* helpful follow-up from you as a reviewer?
A) "Okay, I'll add 8 hours to the estimate. International character sets are always tricky!"
B) "That's a good point. Could you elaborate on what specific edge cases you anticipate? Perhaps we can break this down into smaller tasks and estimate each individually."
C) "Four hours is ambitious for that scope. Let's just stick with the original estimate – we don't have time to over-engineer it."
D) "Thanks for flagging that! I'll update the task description to include 'international character set support' and add a note about potential performance impacts."
The best response (B) demonstrates proactive investigation and collaborative risk assessment. It acknowledges Mark's concern, seeks clarification on the specific unknowns, and proposes a more granular approach to estimation – crucial for realistic development planning. Options A and C are overly simplistic or dismissive of potential challenges; D is a passive acknowledgement without actively seeking information. This aligns with best practices in dev-workplace communication.
13 / 19
During a code review of a new API endpoint for user profiles, Sarah (the junior developer) provides an initial estimate of 4 hours to implement and test. Mark (the senior engineer) responds with: "That sounds reasonable, but let's factor in the potential need to handle edge cases around international character sets – we've seen that cause unexpected slowdowns before." Which of the following is the *most* helpful follow-up from you as a reviewer?
The best response acknowledges Mark's concern while still guiding Sarah towards a more detailed estimation process. Simply accepting the initial estimate without further questioning misses an opportunity to surface potential issues. Option 3 is too dismissive; option 1 ignores crucial risk assessment. Option 2 lacks practical guidance – it simply asks for more information without suggesting action. Option 4 proposes a structured approach, which is what's needed in this scenario.
14 / 19
Mark (the senior engineer) responded with: "That sounds reasonable, but let's factor in the potential need to handle edge cases around international character sets – we've seen that cause unexpected slowdowns before." Which of the following is the *most* helpful follow-up from you as a reviewer?
A) "Okay, I'll add 8 hours to the estimate. International character sets are always tricky!"
B) "That's a good point. Could you elaborate on what specific edge cases you anticipate? Perhaps we can break this down into smaller tasks and estimate each individually."
C) "Four hours is ambitious for that scope. Let's just stick with the original estimate – we don't have time to over-engineer it."
D) "Thanks for flagging that! I'll update the task description to include 'international character set support' and add a note about potential performance impacts."
The best response (B) demonstrates proactive investigation and collaborative risk assessment. It acknowledges Mark's concern, seeks clarification on the specific unknowns, and proposes a more granular approach to estimation – crucial for realistic development planning. Options A and C are overly simplistic or dismissive of potential challenges; D is a passive acknowledgement without actively seeking information. This aligns with best practices in dev-workplace communication.
15 / 19
During a standup update, David says: 'I'm estimating 8 hours to refactor this legacy module.' Maria, the team lead, asks, 'Can you break that down further? What assumptions are you making?' Which response best demonstrates an understanding of time estimation nuance?
The best response acknowledges the inherent uncertainty of an initial estimate while demonstrating openness to further discussion. Option A is dismissive and unprofessional. Option C overstates certainty, which isn't realistic. Option D highlights a valid concern but doesn't offer a practical approach to refining the estimate – Maria was seeking more detail.
16 / 19
You're writing a pull request description for a feature that involves integrating with a third-party API. The task is estimated at 24 hours. Which of the following statements best reflects how to communicate this estimate effectively?
Providing context around the factors influencing the estimate demonstrates professionalism and transparency. Option A is overly simplistic and doesn't explain the reasoning behind the timeframe. Option C minimizes the effort, while option D lacks specific details about potential risks or complexities. The correct response highlights key considerations for API integration.
17 / 19
During a code review of a new microservice, Alex (the developer) provides an estimate of 'around 3 days' for implementing the data validation logic. Ben (the senior engineer), noticing Alex hasn't specified any assumptions, responds: 'That sounds like a significant range. Could you elaborate on what factors might cause that timeframe to shift?' Which approach does Ben demonstrate?
Ben correctly identifies that 'around 3 days' is insufficiently specific. The response highlights the importance of quantifying uncertainty in estimates – a broad range signals potential problems and requires further investigation. Options A and D are dismissive, while option B doesn't address the underlying issue.
18 / 19
You're asked to estimate the time required to migrate a large database schema to a new platform. The documentation is incomplete and provides limited technical details. Which of the following statements best represents an appropriate approach for communicating your initial estimate?
Given the incomplete documentation, it's crucial to acknowledge the inherent risk and uncertainty. Providing a range (5-7 days) demonstrates realistic expectations while recognizing potential challenges. A single, confident number is misleading and unprofessional in this situation. Option D correctly identifies the need for more information, but doesn't present an initial estimate.
19 / 19
Sarah, a junior developer, estimates that building a new UI component will take 48 hours. Her manager, David, replies: 'That's ambitious for this sprint. Let's break it down into smaller tasks and revisit the estimate after completing those.' What does David's response primarily focus on?
David's response highlights the importance of managing scope and mitigating potential risks associated with a large, potentially inaccurate estimate. He's advocating for a more controlled approach – breaking down the work into smaller tasks allows for better tracking and adjustments. Options A and B are inappropriate directives, while option D is prioritizing speed over sound estimation practices.
What does the "Time Estimates — Estimation Language Exercises" exercise cover?
Express hedged time estimates, conditional qualifiers, revised estimates, and order-of-magnitude ranges professionally in English. Intermediate exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Time Estimates — Estimation Language Exercises"?
This exercise has 19 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Estimation Language exercises?
Browse the full Estimation Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.