Estimation Phrases: Giving Realistic Time Estimates
5 exercises on estimation phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
A colleague asks how long the new feature will take. You need to say 'it depends' professionally. Which response works best?
Option C is the professional version of 'it depends'. It names the specific variable (legacy browser support) and quantifies the impact (could double the work). Bare 'It depends' (A) is technically accurate but gives the listener nothing actionable. 'I don't know, it depends on things' (B) is vague and sounds unprepared. 'Depends on lots of stuff' (D) is casual and similarly unhelpful. Whenever you need to hedge an estimate, name the specific conditions: 'It depends on X — if X, then Y; if not X, then Z.' That turns a non-answer into a useful conditional.
2 / 5
Your manager needs a rough number but you haven't looked at the details yet. Which phrase gives a ballpark without over-committing?
Option B is the sweet spot between being helpful and staying honest. It offers a concrete number ('a week'), labels it explicitly as a rough ballpark, and identifies the condition that could change it (looking at the schema). 'I can't give a number' (A) is unhelpful — managers often need even a rough figure to plan. 'Maybe a week or maybe two weeks' (C) gives a range but no reasoning, which is harder to act on. 'A week, definitely' (D) is overconfident when you haven't done the analysis. Always pair a rough number with the caveat that anchors it.
3 / 5
You are asked to estimate work that involves an unfamiliar API. What is the most professional response?
Option D demonstrates the spike technique — a time-boxed investigation before committing to an estimate. It is the professional standard for unknown territory. 'I need more time to think' (A) is vague and gives no plan. 'I'm not sure yet' (B) is honest but passive — it doesn't tell the team what you'll do next. 'I'll estimate later' (C) defers without a commitment. A spike converts uncertainty into knowledge. By naming it, setting a duration ('a day'), and committing to a follow-up estimate, you show maturity and protect the team from a badly-informed commitment.
4 / 5
You want to give an estimate that depends on a third-party integration behaving predictably. Which phrase best expresses the conditional?
Option A is correct. It leads with the assumption ('Assuming no surprises in the third-party integration'), which makes the estimate conditional and protects you if that assumption breaks. The estimate itself ('two sprints') is then clear and confident. 'Two sprints, no problem' (B) is overconfident — third-party integrations are a common source of delays. 'It will take two sprints' (C) sounds unconditional, which is risky. 'Two sprints if everything goes to plan, probably' (D) hedges but the vague 'probably' and 'everything goes to plan' do not identify the actual risk. Name your assumptions explicitly.
5 / 5
You have estimated three days for a task but want to add time for testing and review. Which phrase communicates the buffer professionally?
Option C is the professional way to justify a buffer. It names exactly what the buffer covers (testing and review), and gives concrete numbers (five days vs three), so stakeholders can see what they're getting for the extra two days. 'I'll add extra time just in case' (A) sounds like padding for its own sake. 'We need padding' (B) is vague and might prompt pushback. 'Three days plus some extra' (D) is casual and gives no rationale. Buffers are legitimate — but they earn trust when you explain what they cover, not when you hide them in a rounded-up number.