What is Estimation?
Estimation
Estimation is the practice of predicting how much time, effort, or cost a piece of work will require before anyone starts it.
Estimation is the practice of predicting how much time, effort, or cost a piece of work will take before anyone starts it. Every schedule, every budget, and every commitment a team makes to a client rests on an estimate made in advance, usually with less information than anyone would like.
Estimation is also one of the most consistently wrong skills in knowledge work. Daniel Kahneman and Amos Tversky named the pattern the planning fallacy in 1979: people predict task duration based on a best-case scenario, even when they know from experience that similar tasks have run long before. The bias survives experience. A team that missed its last five estimates will, on average, still underestimate the sixth.
This entry covers estimation as a general skill, the biases that distort it and the techniques that reduce them, applied across tasks, projects, and budgets. For the specific methods teams use to size backlog items during planning, story points, t-shirt sizes, and hours, see sprint planning. For turning an estimate into a tracked budget, see project budget.
The Planning Fallacy: Why Estimates Run Short
Kahneman and Tversky's research described two ways of predicting how long something will take. The inside view builds an estimate from the specific plan in front of you: these are the steps, this is how long each should take, add them up. The outside view ignores the plan entirely and asks a different question: how long did similar work take last time?
Most people default to the inside view, and the inside view is where the optimism creeps in. A step-by-step plan naturally describes the smooth path, the one where nothing goes wrong. The outside view corrects for this because past actuals already include the interruptions, revisions, and surprises that a fresh plan doesn't yet know about. Teams that build the outside view into estimation, checking a new estimate against how long comparable work took before committing to it, catch the optimism before it becomes a missed deadline.
Other Biases That Distort Estimates
The planning fallacy isn't the only pattern that pulls estimates away from reality.
- Anchoring: the first number said out loud in a room becomes the reference point everyone else adjusts around, instead of each person reasoning independently
- Best-case bias: estimating the path where nothing interrupts the work, no revisions, no blocked dependencies, no sick days
- Scope-blindness: estimating the work that's visible at the start and missing the work that only becomes visible once the task is underway
- Pressure bias: quietly shrinking an estimate to match what a client or manager wants to hear instead of what the work needs
Estimation Techniques Beyond Story Points and Hours
Sprint planning covers story points, t-shirt sizing, and hours as ways to size backlog items. These techniques address a different problem: reducing bias in the number itself, regardless of what unit it's expressed in.
| Technique | How it works | What it corrects for |
|---|---|---|
| Reference class forecasting | Find the closest comparable past project or task and use its actual duration as the starting point | The inside view's tendency to imagine a smooth path |
| Wideband Delphi | Each person estimates independently and in private first, then the group compares and discusses gaps | Anchoring on whoever speaks first |
| Decomposition | Break a large task into pieces small enough that each one is easy to reason about individually, then sum the pieces | Scope-blindness on large, vague items |
| Range estimation | Give a range with a stated confidence level instead of one number, for example 80% confident it lands between 6 and 10 hours | False precision in a single number |
How to Measure Your Own Estimation Accuracy
Improving estimation starts with a number: the accuracy ratio, actual time divided by estimated time. A ratio of 1.0 means the estimate landed exactly. Above 1.0 means the work ran long. Tracked by task type over a stretch of work, the ratio reveals where a team's bias lives, instead of treating every miss as a one-off.
| Task type | Avg estimated hours | Avg actual hours | Accuracy ratio |
|---|---|---|---|
| Landing page design | 6 | 7.5 | 1.25 |
| Client revision round | 2 | 3.5 | 1.75 |
| Blog post draft | 3 | 3.2 | 1.07 |
| New integration research | 4 | 9 | 2.25 |
How to Improve Estimation Accuracy Over Time
Estimation accuracy improves with a feedback loop, not with more experience alone. Log the actual time or cost against every estimate, not only the ones that missed. Review accuracy by task type on a regular cadence, monthly or quarterly, since the bias usually concentrates in a handful of task types rather than spreading evenly. Apply the measured ratio as a correction factor going forward: if client revisions run 1.75x the original estimate on average, multiply new revision estimates by roughly that amount instead of estimating from scratch each time. Recalibrate the ratio as new data comes in, since it will shift as the team, the work, and the client relationship change.
Tracking Estimation Accuracy in Melororium
Work Reports in Melororium logs actual hours per task against the original estimate, so a team can see its own accuracy ratio by project or task type instead of relying on memory or gut feel. Anomaly detection in Work Reports flags tasks that ran well past their estimate, which is the fastest way to spot a pattern worth correcting before it repeats across an entire quarter.
In Melororium
Compare estimated vs actual hours in Melororium
Common mistakes with estimation
What teams get wrong most often, and what to do instead.
- 1
Never checking the estimate against the actual
Moving from one estimate to the next without recording what happened. Without that comparison, a team repeats the same misjudgment indefinitely, because nothing ever surfaces the pattern.
- 2
Padding in secret instead of stating a range
Quietly inflating a number to protect against being wrong, rather than giving an honest range with a stated confidence level. Secret padding hides the real uncertainty from everyone who needs to plan around it.
- 3
Estimating in a vacuum, without the person doing the work
A manager or salesperson sets the number alone and hands it to the delivery team as a commitment already made. The person closest to the work usually has information the estimator doesn't.
- 4
Treating an estimate as a promise
Once a number gets said out loud, it turns into a deadline nobody is allowed to revisit, even after new information changes what the task requires.
Frequently asked questions
Is estimation the same as a quote or a budget?
No. An estimate is the internal prediction; a quote or budget is the commitment built from that estimate, usually with contingency added on top. Keeping a gap between the two protects the team when the estimate turns out to be optimistic.
Should estimates be given as a single number or a range?
A range is more honest. A single number implies a precision the work doesn't have. Stating a range with a confidence level, for example 80% confident it lands between 6 and 10 hours, communicates the real uncertainty instead of hiding it.
Does more experience automatically make someone better at estimating?
Not on its own. Experience improves technique, but the planning fallacy persists unless someone deliberately tracks their own accuracy over time. A person can have ten years of experience and still default to the optimistic inside view every time.
Who should give the estimate, the person doing the work or their manager?
Whoever will do the work, whenever possible. Estimates imposed from outside the delivery team tend to run less accurate and get less buy-in than ones the person doing the task arrived at themselves.
How does Melororium help with estimation?
Work Reports compares estimated hours against actual logged time by task and project, so a team can measure its own accuracy ratio and see which task types consistently run over before those patterns cost a quarter's worth of margin.
