EstimationGENERALTEAM-SPECIFICCONTESTEDILLUSTRATIVE

Communicating Uncertainty

A range you know and a point you say is a lie by rounding. Estimates should carry their uncertainty — what is known, what is assumed, what has not been discovered yet — in a form the listener can plan with, without false precision and without hiding behind "it depends".

The moveWorked exampleNext questions▶ Estimation Lab

The situation, the reflex, and why it stalls

Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.

The question

You have a decomposed estimate with wide pieces in it. How do you tell someone who needs a date, without either inventing precision or refusing to answer?

The situation

You did the decomposition. You know the store is most likely six to seven weeks and could be ten. The founder has a launch event in five and asks "can we do it?" — and you can feel the pull to say "should be fine" because the alternative sounds like an excuse.

The reflex

Collapse the range to whichever end the listener wants to hear, and keep the uncertainty to yourself as a private worry. It keeps the conversation short, it avoids sounding unsure in front of someone who is paying, and it feels like the professional thing: they asked for a date, you gave one.

Why it stalls

The private worry becomes a public surprise. The listener planned around the point you gave, and the range you kept to yourself arrives as a late-stage "it is taking longer", which reads as a failure of execution rather than what it was — a failure of communication.

What the reflex produces — and fails to produce
  • The private worry becomes a public surprise. The listener planned around the point you gave, and the range you kept to yourself arrives as a late-stage "it is taking longer", which reads as a failure of execution rather than what it was — a failure of communication.
  • Precision is inferred from format. "Six weeks" sounds measured; "six-ish" sounds unmeasured; neither says which pieces are soft, so the listener cannot help — they could have cut the admin page or found someone who knows the provider, and were never given the information to.
  • The other collapse — "it depends, I really cannot say" — is just as motionless. It feels honest and it is useless: the listener still has an event in five weeks, and now they also think you have not thought about it.
  • Unknown unknowns are left out entirely because they are, by definition, not on the list. An estimate that only covers the pieces you named is an estimate of the pieces you named, and the sentence that says so is the one most often omitted.
ProblemUnderstandRequirementsConstraintsUnknownsDecompositionSmallest StepModelExperimentObserveDebugLearnIterate

The move

Precisely enough to apply it to a problem you have never seen — not a slogan.

  • Separate the three things an estimate is made of and say each one: what you know (pieces you have built before, with narrow ranges), what you are assuming (the decisions the estimate rests on), and what you have not discovered yet (the pieces whose range is wide because they are unfamiliar). The listener can act on each of those differently, and cannot act on a total.
  • Give the range with its shape, not just its ends: "most likely here, could be there, and here is the one piece that decides which". A range with a named driver is plannable — the listener can ask about the driver. A bare range is just a wider point.
  • Say what would narrow it and what it would cost to find out. "Two days on a payment spike would tell us whether it is six weeks or nine" turns uncertainty from a confession into an option the listener can buy (Unknown, Question, Experiment).
  • Leave room for what is not on the list, and say so in a way that is not a shrug: "every store I have seen had one requirement nobody mentioned until checkout existed; I have not budgeted for this one's because I do not know it yet" (Unknown Unknowns).

Three kinds of thing in every estimate

Known, assumed and undiscovered are not degrees of the same confidence. They are different objects with different owners: known pieces belong to the estimator, assumptions belong to whoever can confirm them, and undiscovered pieces belong to an experiment. The board keeps them apart so that the conversation can, too.

The entries under "unknowns" are the ones that would have been rounded away by "should be fine". Each has become a question and a small experiment, which is what makes it something the listener can choose to fund.

The store estimate, sorted by who can act on it
known
  • Catalog, cart, orders and admin: shapes built before, ranges narrow, worst cases about details.
  • Checkout without payment: known once the cart shape is fixed.
assumed
  • ~One warehouse and one currency in V1 — confirmed by the founder in this conversation.
  • ~No guest checkout — *corrected* by the founder in this conversation; the cart piece widened and the estimate moved.
  • ~A provider test mode that a script can drive — to be verified in the payment spike.
unknown → question → experiment
  1. ? Payment is the scary bit.

    becomes Is this provider a hosted-redirect integration or an API-and-confirmation one, and which does the founder accept for launch?

    experiment A two-day spike: one test-mode payment each way, ending with a written note on which the confirmation flow requires and how the order learns it is paid.

  2. ? Something always comes up.

    becomes What requirement will appear the first time a real order is placed — receipts, refunds, an address format, a tax line?

    experiment Walk the founder through placing one order on paper, from cart to confirmation email, and write down every noun they mention that is not yet in the decomposition.

The second unknown is the one that is usually omitted. It cannot be estimated, but it can be *looked for*, and the paper walkthrough is how.

The same estimate, said three ways

The ladder below is the estimating version of a question ladder. The vague form is the reflex; the better form has a range but no structure; the best form is what the listener can plan with. Read the why — it says what the best form makes possible that the others do not.

Answering "how long?"
vague"Should be fine — about five weeks."
better"Somewhere between five and ten weeks, hard to say."
best"Most likely six to seven. Five is possible if payment is the simple kind; I can find out with a two-day spike. If you need five with confidence, we drop the admin page for launch. This assumes one warehouse and a scriptable test mode."

why Only the best form gives the listener something to *do*: fund the spike, cut a piece, or correct an assumption. The vague form gives them a promise; the better form gives them a worry; neither gives them a decision.

Hedging against structuring
Hedged
"It depends on a lot of things — could be quick, could take a while, I would rather not commit until we know more."
Structured
"The driver is payment. Two days would tell us which of two shapes it has; one shape lands in six weeks, the other in nine. Everything else is a shape I have built."

Both sentences admit uncertainty. Only the second locates it, prices the experiment that resolves it, and says what is *not* uncertain — which is most of the estimate.

When the range resolves

Communicating uncertainty is not a single conversation. The pieces resolve one at a time, and each resolution should move the written estimate where the listener can see it. The table below is the estimate's life: what changed, what it did to the range, and whether it was a surprise.

The last row is the category nobody can list in advance. It is on the table anyway, as a line item with no number, so that when it arrives it is a resolution rather than an excuse.

EventPieceRange beforeRange afterSurprise?
Founder says guest checkout is essentialCart1–2–42–4–6No — assumption corrected in the first conversation
Payment spike: hosted redirect onlyPayment3–6–154–5–7No — the wide piece resolved to its middle
Provider confirmations need a public URLDeployment1–2–52–3–5, moved earlierNo — found in the spike
Founder mentions receipts during the paper walkthroughNew piece: receipt email1–2–3Partly — found by looking, before it was late
Tax line required by the accountantNew piece: tax2–3–6Yes — the undiscovered category, arriving as planned

How to do it

Most important first.

  • Lead with the likely case and the driver of the width, in one sentence. Ends of the range come second; the list comes third, if asked.
  • Name assumptions as assumptions, in front of the listener, so that they can correct them now instead of discovering them later. "This assumes guest checkout is not in V1" is a sentence that either gets a nod or saves a week (Assumption vs Requirement).
  • Offer the experiment that narrows the widest piece, with its price. Let the listener decide whether to buy certainty.
  • When asked for a single date, answer with the date you would bet on and the date you would be confident of, and say which pieces separate them. Refuse to give one without the other.
  • Write the estimate down with its ranges and assumptions, and revise it in the same document when a piece resolves (The Decision Journal). An estimate that lives in a chat message cannot be revised, only contradicted.

Worked on a concrete problem

The move has to produce something. This is what it produced.

  • The founder: "can we launch in five weeks?" The answer: "Most likely it is six to seven; five is possible if payment turns out to be the simple kind, and I can find that out with a two-day spike. If we want five with confidence, the piece to drop is the admin page — you would edit products directly for the first weeks. Here is what I am assuming: one warehouse, no guest checkout, a provider with a scriptable test mode."
  • The founder hears three things they can act on: buy the spike, cut admin, or correct an assumption. They say guest checkout is actually essential. The cart piece widens, the estimate moves by a known amount, and it moved *now*, in a conversation, instead of in week four.
  • The chat app, same move: "message delivery is a shape I have built; the realtime layer I have built once; read state across devices I have never built, and it is the piece that could double the estimate. I would like to spike read state before we talk dates." The realtime piece, which sounds harder, is not the driver — and saying so is the information.
  • What was *not* said: "should be fine". Also not said: "it depends". The middle is a sentence with a likely case, a driver, an experiment and a list of assumptions, and it takes about as long to say as either evasion.

How you know it worked

What now exists that did not before, and what question you can now ask.

  • The listener asks a question about a *piece* — "what does the payment spike involve?" — which means the uncertainty was communicated as structure rather than as mood.
  • An assumption was corrected in the conversation, and the estimate moved visibly as a result.
  • The estimate exists in writing with its ranges, and the version after the spike is a revision of it rather than a new number.
  • Nobody was surprised in week four. Late news arrived as "the wide piece resolved to its worst case", which was on the table from the start.

The questions you can now ask

The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.

Next questions
  • ?What do I know, what am I assuming, and what have I not discovered yet — and have I said each of those out loud?
  • ?What single piece drives the width of this range, and what would it cost to find out which way it goes?
  • ?Which assumption, if wrong, moves the estimate the most — and has the person who could correct it heard it?
  • ?If they need a date, what date would I bet on, what date would I be confident of, and what separates them?
  • ?Where is this estimate written down so that it can be revised rather than contradicted?

What can go wrong

How the move itself fails
  • Every sentence becomes a hedge. "It could be anywhere from three to fifteen weeks depending on many factors" is a range so wide and so undriven that it communicates nothing except reluctance. A range needs a likely case and a named driver or it is a refusal.
  • The uncertainty is communicated once and then forgotten. When the spike resolves, the estimate is not revised in front of the listener, so they still carry the old range and its old caveats.
  • The assumptions list becomes a liability shield — a page of "assuming X" written so that no outcome can be blamed on the estimator. Assumptions are for the listener to correct, not for the estimator to hide behind; three that matter beat thirty that do not.
  • The move is applied to someone who genuinely only needs a yes or no — a colleague asking whether a fix will land today. Not every estimate is a planning document; match the shape of the answer to what the question is for.
What the move costs
  • Saying "could be ten weeks" to someone with a five-week event starts a hard conversation that "should be fine" postpones. It only postpones it.
  • Communicating structure takes longer than communicating a number, and some listeners will hear the ranges as evasion the first time regardless of how they are framed.
  • Offering the spike as an option means the listener may decline it, and then the wide piece stays wide with everyone's consent — which is better than it staying wide in secret, and still uncomfortable.
Misreads
  • "So never give a single number." Give one when asked, with the confidence date beside it and the pieces that separate them. The rule "never commit to a date" is falsifiable and false: a date you would bet on, stated as a bet, is a commitment the listener can plan around.
  • "Wider ranges are more honest." A range is honest when its width matches what you know. Widening it past that to feel safe is the same misrepresentation as narrowing it to feel confident, in the other direction.
  • "The unknown unknowns caveat covers everything." It covers the *category*; it does not excuse a missing piece you could have found by asking one more question. The caveat is for what could not be discovered yet, not for what was not looked for.

Where this applies

Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.

  • GENERALKnown / assumed / not-yet-discovered is the shape of any estimate — a feature, a migration, a research question — and the listener can act on each part differently regardless of what is being estimated.
  • TEAM-SPECIFICTo a founder or client the estimate is a planning input and needs the driver and the option to buy certainty; to a teammate it can be the raw list. To a manager who forwards numbers upward, the likely case will travel alone unless the range is written down where it will be read.
  • CONTESTEDSome experienced engineers hold that ranges are a way of never being wrong, and that a team that commits to a single date and treats it as a constraint delivers more because the date shapes the scope rather than the other way round. The strongest form of this view is that a range is only useful if someone has to pick a point from it anyway, so the estimator should do that work rather than pass it on. This lesson answers that the point should be given — as a bet, beside a confidence date, with the pieces that separate them — so the listener gets both the commitment and the structure.
  • ILLUSTRATIVEThe founder, the launch event, the five weeks and the two-day spike are invented to show the shape of the conversation; no real schedule is being described.

Where the depth lives

This domain asks the question and hands the answer off by name.

Further
  • The manifesto's review page at /manifesto/review is about checking an answer before trusting it; an estimate is an answer too, and the same habit applies to your own.