Estimates feel like control. Mostly they hide how much you don’t yet know. The Uncertainty ListUncertainty ListThe team's living list of open unknowns — sized 1/3/5, phrased as questions, reviewed daily and in planning, chipped away each week. is the tactic that puts the unknownsUncertaintyWhat the team does not yet know — sized and tracked deliberately rather than hidden inside estimates. back in the open — named, sized, and tracked like real work. Where the Initiative DocumentInitiative DocumentThe PR/FAQ-shaped document where an initiative's context lives — customer, solution, plan, business case, and success metrics. captures what and The ApproachThe ApproachThe multi-week narrative roadmap — titled weekly outcomes ("The one where…"), each with a demo, planned backwards from success. captures when, the Uncertainty List captures what we don’t know yet, and makes sure the team chips away at it.

It is owned by the team and lives wherever the team’s other artifacts live: a shared doc, a section of the ticket system, or the Check-inDaily Check-inA 15-minute daily ritual where the team surfaces reality and unknowns rather than reporting status. itself.

Why estimates hide uncertainty

A single number for a fuzzy task launders doubt into false confidence. Innovation produces uncertainty by definition — pretending a story-point estimate has resolved it only defers the surprise to a worse moment. The honest move is to name the Uncertainty, not bury it in a point value. A dedicated list makes the unknowns visible and fundable, so prioritisation gets driven by what the team doesn’t know, not just by scope.

A list sized to the project

Don’t try to list everything — list the ones that matter, scaled to the initiative:

  • Small projects — name one key uncertainty.
  • Medium projects — name the top three.
  • Large projects — name the top five.

Capture each as its own ticket or task, aimed specifically at reducing that one uncertainty.

Phrase them as questions

Use an If/Then or Will/When shape so each item points at an experiment, not at an anxiety:

  • “If we launch this feature, will the system handle it smoothly?”
  • “If we delay this project, will Sales get hurt, or are they fine showing prototypes a while longer?”

The biggest uncertainties usually fall into four buckets worth checking by name:

  • Desirability — will customers actually use or buy it?
  • Usability — can they figure it out?
  • Feasibility — can we build it?
  • Viability — does it work for our business?

An Initiative Document moves from draft to ready when these four are answered well enough to commit. They are the uncertainties most worth acting on early.

The learning loop

Working the list is the #REALITY pillar in motion, and it runs on the loop that drives Learning rateLearning rateThe speed at which a team turns uncertainty into knowledge — the method's true KPI, driven by the expectation→change→review loop.:

  1. Make expectations explicit — what you believe, how long you think it takes, what impact you expect.
  2. Do the smallest thing that tests it, then document what changed and why.
  3. Review the lessons and adjust the plan.

The goal of the week is the update, not the output.

Example · #LEARNING

A team unsure whether users would trust an auto-import wrote the unknown as a question — “If we auto-import their data, will users trust it enough to keep it on?” — and turned it into a Things to Figure OutThings to Figure OutEach person's one thing to figure out today, framed as a Why/How/What/When question that resolves into a Lesson Learned.. Two days on a throwaway prototype killed the feature and saved a month. The Lesson Learned was the deliverable.

How the list gets used

The list is not a parking lot. It is worked on three rhythms:

  • Daily, in the Check-in. Ask each person “what’s your biggest uncertainty right now?” Resolve it on the spot if you can; if not, decide where it goes — a Collab time deep-dive, the next Week Planning, a retrospective, or a new Things to Figure Out (TFO).
  • In Week Planning. Look at the list and ask “what can we do to reduce these?” Convert the top items into TFOs or weekly demo objectives. The goal is not to solve everything at once; it’s to chip away.
  • In retrospectives. Review the list across the week or month and look for recurring themes — they signal where the team needs more context, training, or alignment with another team.

A TFO is simply an uncertainty in motion: it starts as a Why / How / What / When question and resolves into a Lesson Learned that feeds back into the Initiative Document and The Approach. That is the path from “we don’t know” to “we know now.”

Why teams resist it — and the fix

Teams under-use the list for three predictable reasons: it can feel like waterfall planning, like making promises to management, or like admitting weakness. The discipline that fixes it:

  • Keep it a team artifact first.
  • Frame uncertainties as questions, not as failure points.
  • Put estimates in the text of tickets, not in story points — a point value invites the unknown to be read as a commitment.
  • Let management see only the patterns and the lessons, not the raw list.

Kept honest, the Uncertainty List makes a team measurably better at estimating, calmer in the face of change, and more trusted across the business. The teams that keep it are the ones that stop being surprised.

Template

Project size: small (1) / medium (3) / large (5) → number of uncertainties

Uncertainty (as If/Then or Will/When): …?

Size (1/3/5):

How we’ll reduce it: the smallest experiment — becomes a TFO or demo objective

Assigned to (week / owner):

Lesson Learned on resolution: … (feeds the Initiative Document + Approach)