Estimation under uncertainty

A householder asks a well driller how deep the new borehole will go, since drilling is priced by the metre. With no drilling log for the plot, she quotes 30 to 90 metres and names her assumption: the water sits in the same gravel as the next-door well. Re-reading the geological map that evening would not narrow the quote; a narrow test hole that finds the top of the gravel would. Her notebook pairs every past quote with the depth actually drilled, and in this valley she has gone deeper than quoted every time.

At the borehole	In an estimate
30 to 90 metres, "if the gravel is the neighbour's"	a range and its assumption (step 3)
re-reading the same map	more estimating with no decision (step 6)
the test hole	a spike on one unknown (step 7)
quoted depth beside drilled depth	actual ÷ estimate, logged (step 11)
deeper than quoted, every time, in this valley	parts leaning one way (step 12)

Breaks down when: the rock does not change while she drills, but a product can be redefined mid-project. Wrong inference: "once the test hole is in, the range can only shrink." A redefined scope widens it again (step 8). A borehole also has one depth, while an estimate adds many parts, each with its own range.

In real terms: each estimate carries its low end, its high end and the assumptions behind them, and each closed task adds one actual-over-estimate ratio to the log.

EXH-2600 is a synthetic estimate of Arabic right-to-left support for the ExamHall candidate app, split into four parts in working days.

EXH-2600 · Arabic right-to-left support, candidate app · working days · ends summed
  layout mirroring                3–4   known: logical CSS properties are already used
  code snippets in Arabic text    2–10  open: how a snippet displays inside right-to-left text
  date formats                    1–4   open: which formats the exam centres want
  PDF export                      2–8   open: whether the PDF library joins Arabic letters
  kickoff                    total 8–26 days (high ÷ low 3.25)
  decision: one date format  date formats 1–4 -> 1–2 · total 8–24 days (high ÷ low 3.00)
  2-day spike on snippets    code snippets in Arabic text 2–10 -> 2–4 · total 8–18 days (high ÷ low 2.25)
  widest part left: PDF export 2–8; the low end assumes the library joins the letters

At kickoff three of the four parts are open, so the range runs from 8 to 26 days. Deciding one date format is a decision, not more estimating, and it trims the top. The spike settles the snippet question, and the range narrows again. Lina announces 8–18 days and names the PDF assumption that holds the low end.

MR !2900 adds the work to the team's estimate log: five closed tasks, each estimate beside its actual.

MR !2900 · estimate log, five closed tasks · working days, estimate -> actual (actual ÷ estimate)
  seat-map filter 3 -> 4 (1.33) · proctor notes 5 -> 6 (1.20) · timer banner 2 -> 3 (1.50) · locale switcher 8 -> 10 (1.25) · alert sound 4 -> 5 (1.25)
  over 5 of 5 · under 0 · summed plan 22 -> 28 (1.27): no overrun is offset
  RTL support · announced 8–18 after the spike · actual 15 · inside the range

Every task ran over, so adding them did not cancel anything: the summed plan ran over too. The ratio column, not one remembered task, is what the next estimate is calibrated with. The script replays fixture figures; it does not measure a real team.