Skip to content

Estimation

Estimates are always wrong. That's not a failure — it's the nature of estimating anything that hasn't been done before. The goal of estimation is not accuracy. It is:

  1. To force a conversation about scope before work starts.
  2. To give the team a reference point to learn from.
  3. To support capacity planning, which is a different problem from being right.

Why estimates are wrong: the planning fallacy

Daniel Kahneman won a Nobel Prize partly for documenting the planning fallacy (Kahneman & Tversky, 1979; Kahneman, 2011). We routinely underestimate how long tasks take, because we estimate as if everything will go well — and almost nothing goes well.

The cure is reference-class forecasting: instead of estimating from first principles ("how long should this take?"), look at how long similar things actually took in the past and use that as the base rate.

How dooer supports estimation

dooer has an explicit effort-estimation negotiation cycle:

  1. The assignee proposes effort_hours (after reading the brief).
  2. The assigner sees the proposal in /approvals and either approves or rejects with comment.
  3. Approved estimates are locked. Pending estimates can be revised.

This is a 2-person version of Wideband Delphi (Boehm, 1981; Cohn, 2005) — a structured estimation technique where multiple people estimate independently, then discuss the disagreement.

The discussion is the learning. When one person estimates 4 hours and the other 12, somebody knows something the other doesn't. Surfacing that asymmetry is the point.

The three estimation rules

  1. Estimate before you commit. Putting a number on it forces clarity. "It'll take what it takes" is not a plan.
  2. Estimate in ranges, not points. "8–16 hours" is more honest and more useful than "12 hours." The single-number culture is a leftover from waterfall.
  3. Track variance, not just outcomes. A team that's consistently 50% over on estimates is not bad at estimating — they are bad at adjusting their estimates. Run a calibration retro quarterly (T-3.6).

What estimates are NOT

  • Commitments. Confusing estimate with commitment is the original sin of project management. An estimate is a probability range. A commitment is a promise. They are different things and should be communicated differently.
  • Performance reviews. If someone misses an estimate, the question is "what did we learn?" — not "why didn't you deliver?" Otherwise people stop estimating honestly.
  • Schedules. Estimating a task takes 8 hours says nothing about when it will be done. That depends on capacity, WIP limits, dependencies, and what else is in flight.

Story points vs hours

You will see two estimation styles in the wild:

  • Hours — what dooer uses by default. Familiar; maps to calendar; works for individual contributors and for projects with predictable team velocity.
  • Story points — relative complexity (Fibonacci: 1, 2, 3, 5, 8, 13). Originally from XP/Scrum (Beck, 2000; Cohn, 2005). Better for chaotic team contexts where calendar mapping is meaningless.

dooer uses hours because the dual-track curriculum spans both solo operators (who think in calendar time) and team leads (who can roll up hours into capacity). Story points are a step you can add on top if you adopt Scrum formally.

Where to read more

  • Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux. Chapter 23 covers the planning fallacy.
  • Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall.
  • McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press.
  • Boehm, B. (1981). Software Engineering Economics. Prentice Hall. Origin of Wideband Delphi.

← WIP and flow | Next: The feedback process →