Estimating Effort and Time, and Why Retrospectives Make It Better
Every technique on this site's project-management pages — a Gantt chart, a critical path calculation, a sprint commitment — consumes a duration estimate as its raw material, and produces a schedule only as trustworthy as that estimate was. This page is about where those numbers actually come from, why they're reliably wrong in a predictable direction rather than randomly wrong, and the specific mechanism — the retrospective — that turns repeated estimation into a skill that improves rather than a guess that never gets better.
Why Software Estimates Are Hard in a Specific, Named Way
Barry Boehm observed, in his 1981 book Software Engineering Economics, that the possible range of a software project's cost or schedule estimate narrows in a predictable, funnel-like shape as the project progresses and more becomes known — he called it the "funnel curve." Steve McConnell later popularised the same shape under the name it's now usually known by, the Cone of Uncertainty, in his 1997 book Software Project Survival Guide and again in Software Estimation: Demystifying the Black Art1.
4x too high to 4x too low"] --> B["Requirements defined
~0.5x to 2x"] B --> C["Design complete
~0.67x to 1.5x"] C --> D["Detailed design
~0.8x to 1.25x"] D --> E["Actual completion
exact, by definition"]
The point of the cone is not the exact multipliers — different sources give slightly different figures — it's the shape: at the very start of a project, before requirements exist in any real detail, an honest estimate has an enormous range, and that range narrows as real information (a settled architecture, a working prototype, completed work) replaces guesswork. The practical consequence is uncomfortable but important: a single-point estimate given at kickoff ("this will take six weeks") is being asked to do something the cone says is structurally impossible — it's being asked to be precise at exactly the moment in the project when precision is least available. Treating an early estimate as a range, and being explicit about which stage of the cone you're estimating from, is more honest than a confident-sounding single number produced too early to support one.
Estimation Techniques, and What Each One Is Actually Good For
| Technique | How it works | Best suited to |
|---|---|---|
| Expert judgement | Someone who has done similar work before gives a number from experience. | Fast, cheap, and often surprisingly good — but only as good as the expert's actual relevant experience, and it doesn't scale or transfer to someone else. |
| Analogous estimating | Find a genuinely comparable past task or project and scale from its known actual duration. | Early-stage estimates where a real historical comparison exists; weak when the new work is genuinely novel. |
| Parametric estimating | A formula derived from historical data across many past projects, taking size/complexity inputs and producing a duration or cost. Boehm's own COCOMO model (also from Software Engineering Economics) is the classic software example, estimating effort from an estimated lines-of-code count and a set of scaling factors2. | Organisations with enough historical project data to calibrate the formula in the first place — it's only as good as the dataset behind it. |
| Three-point / PERT estimation | Optimistic, most-likely, and pessimistic estimates combined via (O + 4M + P) / 6 — see Critical Path Method and PERT for the full mechanism. | Tasks with genuine, describable uncertainty, where a single number would hide a real range worth reporting. |
| Planning Poker | Each estimator privately picks a card (often Fibonacci-like: 1, 2, 3, 5, 8, 13...) representing relative size, then all reveal simultaneously; large disagreements are discussed until the group converges. Devised by James Grenning in 2002 as a faster, less domineered alternative to the older Wideband Delphi estimation method, and popularised widely by Mike Cohn's 2005 book Agile Estimating and Planning3. | Agile teams estimating relative story size rather than absolute duration — its main value is surfacing hidden disagreement (two estimators picking very different numbers usually means they're picturing different work), not the number itself. |
Notice these aren't competing choices so much as tools for different situations: expert judgement and analogous estimating dominate early, when the cone of uncertainty is widest and there's nothing else to go on; three-point estimation and Planning Poker are more useful once there's enough shared understanding of the work to talk meaningfully about a range or relative size.
Why Retrospectives Are the Mechanism That Improves Estimation Over Time
None of the techniques above gets better on its own. Expert judgement only improves if the expert's mental model of "how long this kind of thing takes" gets corrected against what actually happened; a parametric model only improves if new actual data feeds back into it; a team's Planning Poker calibration only improves if it learns, concretely, where its past estimates were wrong and in which direction. The retrospective — a structured, recurring team review of what actually happened against what was expected — is the mechanism that closes that loop. Without it, a team can run the same estimation technique for years and stay exactly as inaccurate as it was on day one, because nothing ever tells it, in a form it can act on, how its guesses have been failing.
Norm Kerth's Project Retrospectives: A Handbook for Team Reviews (2001) is the foundational text on running these well, built around what Kerth called the Prime Directive — the working assumption, stated explicitly at the start of a retrospective, that everyone did the best job they could with what they knew, the skills they had, and the resources available at the time4. That framing matters specifically for estimation: a retrospective that turns into blame for a missed estimate teaches people to hide bad news and pad future estimates defensively, while one that treats a missed estimate as data — what did we not know at the time that we know now? — actually improves the next one.
Concretely, for estimation to improve, a retrospective needs to look at three things together, not just "how did the sprint go":
- Estimated vs. actual, itemised. Not just "we were 20% over," but which specific tasks were over and which were under — the pattern across many small comparisons is far more useful than one aggregate number.
- Why, specifically, for the outliers. "Underestimated the third-party API integration because we didn't know its rate limits" is a fact a team can act on next time; "estimation is hard" is not.
- What changes as a result. An adjustment to how a specific category of work gets estimated next time — a documented, testable change, not a vague resolution to "be more careful."
Run this way, sprint over sprint or project over project, an estimation-focused retrospective is doing for a team's own judgement exactly what feeding real outcomes back into a parametric model does for COCOMO: turning a fixed guess into a calibrated one. See this site's own project-navigation material and Risk Management for retrospective practice applied to project risk specifically, and Scrum for the Sprint Retrospective as the built-in, recurring slot where this review is meant to happen by default rather than only after something goes visibly wrong.
References
Boehm, B. W. (1981). Software Engineering Economics. Prentice-Hall (origin of the "funnel curve"). McConnell, S. (1997). Software Project Survival Guide, and (2006) Software Estimation: Demystifying the Black Art, Microsoft Press (popularised as the "Cone of Uncertainty"). ↩
Boehm, B. W. (1981). Software Engineering Economics. Prentice-Hall — source of the COCOMO (Constructive Cost Model) parametric estimation model. ↩
Grenning, J. (2002). "Planning Poker." Wingman Software. Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall — the book that popularised the technique widely. ↩
Kerth, N. L. (2001). Project Retrospectives: A Handbook for Team Reviews. Dorset House. ↩