6 exercises — name and mitigate common estimation biases (anchoring, planning fallacy, overconfidence, scope creep) in professional English.
0 / 6 completed
1 / 6
A project manager suggests "3 days" as a starting point before you've looked at the code, and your final estimate ends up being 4 days even though the work genuinely warranted 8. What bias should you name in the retro, and how?
Anchoring bias occurs when an initial number (even an arbitrary one, like someone else's guess) unduly influences a subsequent independent estimate — the estimator adjusts insufficiently away from the anchor. Naming it explicitly in a retro helps the team recognise the pattern and mitigate it (e.g. asking estimators to size stories before hearing any suggested number).
Mitigation phrase: "Let's size this independently before anyone shares a number, to avoid anchoring each other." This is a well-documented cognitive bias (Tversky & Kahneman) directly applicable to estimation meetings.
2 / 6
You consistently estimate tasks assuming everything will go smoothly — no interruptions, no unexpected bugs, no code review delays. What is the correct name for this bias, and how do you describe a fix?
The planning fallacy (a form of over-optimism bias) describes the tendency to estimate based on the best-case scenario while ignoring the base rate of how similar tasks have actually gone historically — interruptions, code review cycles, unexpected complexity, etc.
Mitigation phrase: "Let's use reference-class forecasting — look at how long our last 5 similar tickets actually took, not how this one 'should' go in a perfect world." Naming both the bias and a concrete counter-technique (reference-class forecasting) is the professional way to raise this in a retro.
3 / 6
What is the correct way to explain Hofstadter's Law to a stakeholder who is frustrated that a project is taking longer than the original estimate?
Hofstadter's Law is a well-known, semi-humorous but empirically supported observation about the persistent underestimation of software work, even by experienced estimators who try to correct for past underestimation. Explaining it to stakeholders should pair the observation with a practical response — buffers and iterative re-estimation — rather than presenting it as a fatalistic excuse.
Useful phrase: "This is a well-documented pattern, not an excuse — the response is to build in explicit buffer and re-estimate as we uncover more information, not to pretend the original number was exact."
4 / 6
A senior engineer gives a very confident, precise estimate ("exactly 11.5 days") for a task with significant unknowns. What bias might this reflect, and what is the correct way to raise the concern?
Overconfidence bias in estimation shows up as false precision — a single exact number that implies more certainty than the underlying knowledge supports. The correct response is not to dismiss the estimate but to gently suggest expressing it as a range that reflects genuine uncertainty.
Useful phrase: "Given the unknowns, could we express this as a range instead of a single number, to reflect the actual uncertainty?" Ranges are a standard technique (e.g. 3-point estimation: optimistic/likely/pessimistic) precisely to counter overconfidence bias.
5 / 6
A team member says "the last time we estimated a migration project it took 3x longer, so let's just triple every estimate going forward." Why is this an oversimplified response to estimation bias, and how would you phrase a better approach?
This describes the difference between an ad-hoc overcorrection and genuine estimation calibration — using a systematic, ongoing measurement of actual-vs-estimated ratios (ideally segmented by task type) rather than a single anecdote generalised into a blanket rule.
Useful phrase: "Let's track our estimate-to-actual ratio over time, per category of work, so we calibrate based on evidence rather than a single past incident." Calibration is a repeated, data-driven practice — not a one-time multiplier applied forever.
6 / 6
How do you correctly explain "scope creep" as a source of estimation inaccuracy, distinct from the estimate itself being wrong?
It's important to distinguish estimation error (the estimate itself was inaccurate for the defined scope) from scope creep (the delivered scope grew after the estimate was made, without revisiting the estimate). Conflating these leads teams to blame poor estimation for what is actually uncontrolled scope change.
Useful phrase: "The original estimate covered X — this new requirement (Y) wasn't included, so let's re-estimate rather than treating this as the original estimate being wrong." Explicitly re-estimating when scope changes is the correct professional response, rather than silently absorbing the extra work into the same timeline.
What does the "Estimation Bias Language — Estimation Language Exercise" exercise cover?
Practise naming and mitigating estimation biases in English: anchoring, over-optimism, Hofstadter's Law, overconfidence, and scope creep. 6 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 "Estimation Bias Language — Estimation Language Exercise"?
This exercise has 6 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.