Scoping under uncertainty

Join every part with one thin path, add thin slices, spike the biggest unknown, announce a range, and cut scope to keep dates.

Before you read: predict

ExamHall is adding rest breaks for candidates with an accommodation. The candidate's timer, the grading deadline and the proctor view must all change, and the three have never run together. Zara works alone, on one item at a time, in her plan's order. A kind of break runs through all three parts once each part has finished its item for that kind. Her items, in working days:

The team wants to learn as early as possible where the three parts disagree.

Which plan should Zara follow?

timer         fixed 10-minute break, one test candidate   0.5grading       fixed 10-minute break, one test candidate   0.5proctor view  fixed 10-minute break, one test candidate   0.5timer         scheduled breaks, every rule                2timer         medical breaks, every rule                  1.5grading       scheduled breaks, every rule                1grading       medical breaks, every rule                  1proctor view  scheduled breaks, every rule                0.5proctor view  medical breaks, every rule                  1

The 30-second version

Join every part with one thin, hard-coded path, so mismatches show on day one. Then add thin slices, each usable end to end. Spike the unknown most of the estimate waits on before estimating the rest. Announce a range, your confidence and the assumption likeliest to break; re-announce when it breaks. To keep a date, cut slices, not tests.

Join every part with one thin path, add thin slices, spike the biggest unknown, announce a range, and cut scope to keep dates.

How it works

Step 1 of 13

One thin path first. Before building any part out, join every part with one hard-coded case, such as one test candidate.

In the kitchen

The throw line, tied on both banks → One thin path through every part (step 1)

Analogy: A rope crossing over a river gorge (outdoor instruction)

An outdoor centre's instructors rig a rope crossing over a gorge for a school group. Before any heavy rope, one instructor walks a light throw line round by the footbridge downstream and ties it to the far-bank tree: the first thing to span the gorge shows at once whether it reaches and clears the rocks. Each later pull brings one whole, usable thing across. Before planning the rest, the lead tests the tree every rope will hang on. She radios base "40 to 70 minutes, fairly sure, the far tree is the risk", and radios again the moment it fails. When the light fades, she sends fewer bags across, never a thinner rope.

At the gorge	In scoping
The throw line, tied on both banks	One thin path through every part (step 1)
One usable thing per pull	A thin vertical slice (step 4)
Testing the tree every rope hangs on	Spiking what the most waits on (step 7)
"40 to 70 minutes, fairly sure, the tree"	A range, a confidence, an assumption (step 8)
Radioing the moment the tree fails	Re-announcing the day it breaks (step 10)
Fewer bags, never a thinner rope	Cut scope, not quality (step 12)

Breaks down when: the throw line stays and pulls the next rope over, while the thin path's hard-coded pieces are thrown away. Wrong inference: "the first path is part of the product." A crossing is also rigged once; slices keep shipping to users.

In real terms: after the first joined run, every merge leaves something a user can do, and every estimate names the assumption that would break it.

Examples, run for real

EXH-2610 is a synthetic run of the hook: 25% extra time for one hard-coded test candidate, through the timer, the grading deadline and the proctor view, before any per-candidate rule exists.

EXH-2610 · thin path: one test candidate (c-17), +25% hard-coded · 60-minute exam · virtual clock
  pieces: timer 1 · grading 0.5 · proctor view 0.5 days · first joined run on day 2
  timer: c-17 ends at minute 75 · proctor view shows minute 75
  saves at minutes 30, 62, 74 -> timer open for 3 of 3 · grading accepts 1 of 3 (it closes at the exam's minute 60)
  fix: grading reads c-17's end from the timer -> grading accepts 3 of 3

The timer and the proctor view agreed, but grading still closed at the exam's own minute 60, so two of the three saves were refused. Nobody had written that rule down as a question: it appeared on the first joined run, on day 2 of the plan, while every per-candidate rule was still unbuilt. The fix is one line, and the run is repeated.

MR !2910 records the estimate the team announced after a 1-day spike on per-candidate deadlines across reconnects. The confidence comes from the team's own log of earlier ranges.

MR !2910 · accommodations estimate after the 1-day reconnect spike · working days, ends added
  per-candidate extra time from the disability office list 1–2
  rest breaks                                              1–2
  deadline handed over on reconnect                        2–3  (spiked: holds over one reconnect; two in a row untested)
  total 4–7 days · team log: 7 of the last 10 ranges held the actual -> about 70% sure
  announced: "4–7 days, about 70% sure; the risk is the reconnect path"

The announcement names the one assumption the spike left open, so the lead knows what news would change the range. The script replays fixture figures; it does not measure a real team.

Try it

Answer first, then check. Nothing is saved.

Question 1 of 6

A payments-ledger team is adding refunds for its support agents, who are waiting for them. Each refund case needs three pieces, ledger tables, an API and a screen. Lines each piece changes:

Each MR is deployed as it merges, and the team's reviewers take MRs of at most 300 changed lines.

Which split should the team use?

refund case                                 tables  API  screenfull refund, account's own currency          50      90   80partial refund                               10      70   60another currency, at the bank file's rate    70      120  60another currency, a rate the agent types     20      60   50

Question 2 of 6

A payments-ledger team moving to a new bank must give its range by Friday, and has time for one 2-day spike before then. It will build the parts in the table's order. Each part's range is as wide as it is because of the open question it waits on:

Which question should the spike answer, so that its answer can move the team's total range the most?

part                     days  waits onsandbox test setup       1–3   Q4settlement file parser   2–6   Q1matching rules           3–8   Q1statement PDF            1–8   Q2audit export             2–3   Q3balance history view     1–2   Q3month-end job            2–3   Q3Q1  Does the new bank's settlement file mark reversals?Q2  Can the PDF library lay out the 40-column statement?Q3  Does the audit log keep each balance's previous value?Q4  Will the bank's sandbox be ready in the first week?

Question 3 of 6

On Monday morning Omar told the finance lead that multi-currency payouts would take 10–14 working days, about 70% sure, and that the risk was the bank's payout file coming in one format. His parts: the file import 3–4 days, the payout rules 4–6 and the payout screens 3–4. At the end of Wednesday the import is not done: the file comes in three formats, and the import needs 3–6 more days. The rules and the screens are not started, and their ranges still hold. That evening Omar tells the lead again.

When will the payouts be done, as a range of working days counted from Monday?

Question 4 of 6

A payments-ledger team is adding card chargebacks, and the finance lead asks when they will ship. A 2-day spike on the card network's sample files is finished. The team's four parts, in working days:

Which announcement should the team give the finance lead?

part                   days  what the range rests ondispute import         2–3   built like the refund import, shipped in Maynetwork response file  3–5   spiked on the network's sample filesmerchant portal page   2–7   reuses the refund form, not yet checked; a new form 4–7evidence upload        2–4   one PDF per dispute, not yet checked; separate images 5–9

Question 5 of 6

A ledger team has four slices of its statements feature left, in the product owner's priority order, each range in working days including 1 day for its tests: the monthly statement 3–4, the statement emails 2–4, the yearly summary 1–2 and the CSV download 1–2. Its plan is to ship all four, with their tests. The board's date is 9 working days away and will not move. In this ledger, every slice shipped without its tests has cost 2 days of fixes in the week after.

Which change to the plan should the team make?

Question 6 of 6

Two developers start a ledger feature on the same Monday and work side by side; neither waits for the other. Ana builds the ledger tables, 1–2 working days, then the posting rules, 3–7. Ben builds the bank file import, 2–3, then the statement screen, 3–4. The feature is done when both have finished.

What range, in working days from that Monday, does the team announce?

Go deeper

Pro tip

Put the assumption likeliest to break your estimate in the ticket, with the date you will know whether it holds. On that date, check it before standup.

Sources

The curriculum row's only source: O'Reilly, 97 Things (Learning platform, ISBN 9780596800611), chapter 60, https://www.oreilly.com/library/view/97-things-every/9780596800611/ch60.html. No text of it was read, so no claim, step or item here rests on it.
No other source keys anything.

Checked against the tools and docs as of 2026-10-02.

Predict first