Model Three Planning Scenarios Before You Promise a Date

Workflow area: Delivery & Reporting · Tier: Core · Hands-on time: ~35 minutes

The planning conversation goes wrong at the moment a leader answers "when can we have it?" with one number. A single date hides every assumption that produced it, so when an assumption breaks — someone leaves, scope grows, the estimate was hopeful — the date just becomes "missed." Scenario modeling changes the conversation's shape: here are three coherent versions of the future, here is what each costs, here are the assumptions each rests on; pick one. AI makes building three models cheap enough to do for every significant plan — and the discipline of explicit, challengeable assumptions is what keeps the models honest.

When to use — and when not to

• Use it when asked for a committed date on meaningful scopeanything over a few weeks of team effort deserves scenarios, not a point estimate.
• Use it when someone proposes adding people to a late projectthe model will surface the onboarding drag and coordination cost that Brooks's Law predicts and optimists forget.
• Use it at quarter planningrunning the full proposed scope against real capacity, before commitments are made, is the cheapest honesty available.
• Skip it without velocity historya new team or a novel domain has no reference data; use pb-12's outside-view techniques instead and say "low confidence" out loud.
• Skip false precisionif the model outputs "March 17th," round to "mid-March, ±2 weeks"; scenario outputs are ranges, and quoting them as dates re-creates the original sin.
• Skip using scenarios as pressure instrumentsmodeling "what if everyone works weekends" is not a scenario, it's a threat with a spreadsheet; capacity math uses sustainable numbers.

The recipe

1. 1.

   Gather the three inputs honestly. Roster: people, start/end dates, real availability (on-call load, meetings, support rotation — engineers deliver 60–70% of nominal time, not 100%). Velocity history: last 6+ sprints or cycle-time data from the tracker, including the bad sprints — cherry-picked history is pre-baked failure. Proposed scope: the estimated backlog, with estimates labeled by confidence.

2. 2.

   Run the scenario model.

   Copy

   Model three delivery scenarios for a software project. Show
   every assumption and all arithmetic — I need to challenge the
   model, not admire it.
   
   ROSTER: [PASTE — names/roles optional, capacity essential:
   e.g. "6 engineers; 1 on support rotation each sprint; 1 leaves
   Aug 30; contractor starts Sep 15"]
   VELOCITY HISTORY: [PASTE — e.g. "last 8 sprints: 34, 28, 41,
   30, 22 (holiday), 36, 33, 31 points"]
   PROPOSED SCOPE: [PASTE — items with estimates + confidence]
   DEADLINE CONTEXT: [e.g. "stakeholder wants all of it by Nov 1"]
   
   Produce:
   1. BASELINE REALITY — at historical velocity (use the median
      and the 25th percentile, not the best sprint), when does
      the full scope land? State the gap vs. the deadline plainly.
   2. SCENARIO A — CUT SCOPE: what must ship by the deadline at
      realistic velocity; which items fall out (use my confidence
      labels — cut low-confidence-estimate items' benefit of the
      doubt first).
   3. SCENARIO B — ADD TIME: full scope, realistic velocity;
      the honest date range.
   4. SCENARIO C — ADD PEOPLE: model 2 added engineers WITH
      onboarding drag (new joiners at 25/50/75% for their first
      three sprints, and a 10-15% coordination tax on the team).
      State when added people actually change the date — and
      whether that is before the deadline at all.
   5. ASSUMPTIONS TABLE — every assumption in one table: value
      used, source (history / my input / model default), and
      which scenario it moves most.
   
   Rules: ranges, not dates. No scenario where the gap is closed
   by unexplained velocity improvement. If the numbers don't
   support the deadline in any scenario, say so first.
   

3. 3.

   Attack the assumptions table. Good output includes:

   Copy

   ASSUMPTIONS
   - Velocity: median 32 pts (25th pct: 28) — source: history
   - New-hire ramp: 25/50/75% over 3 sprints — model default ← 
     CHALLENGE: your onboarding docs are thin; consider slower
   - Scope growth: 0% — my input ← CHALLENGE: last two projects
     grew 20%+ after start
   
   SCENARIO C: contractors starting Sep 15 reach full output
   ~Oct 27 — they do not materially move a Nov 1 date. Adding
   people is a December strategy, not a November one.
   

   Verify with the team: does the velocity number match their felt reality? Is the availability roster true? A scenario model reviewed only by the leader is a monologue with arithmetic. Adjust inputs and re-run — iteration is cheap now; that is the point.

4. 4.

   Add a scope-growth stress line. Re-run the baseline with 15–20% scope growth (your org's actual historical growth rate if you have it). If Scenario A only works with zero growth, it is not a plan, it is a wish with a burndown chart.

5. 5.

   Present all three, recommend one. Take the scenarios to stakeholders as the decision surface: what each delivers, when, at what cost and risk, resting on which assumptions. Recommend one and say why. The stakeholder may choose differently — that is now their informed choice, on the record, instead of your single date absorbing all future blame.

Make it yours

• Spreadsheet-first version: have Claude's code interpreter (or ChatGPT's) build the model as an actual sheet — inputs on one tab, scenarios computed on another — so planning meetings adjust assumptions live and watch the ranges move; the artifact outlives the chat.
• Kanban/no-points teams: swap velocity for throughput (items/week) and cycle-time distributions; the prompt structure is identical and the honesty requirements are too.
• Program-level (multiple teams): model each team with this recipe, then a second pass for the dependency graph between them — the cross-team wait states, not any team's velocity, usually own the critical path; ask the model to identify which team's slip moves the end date and which slips are absorbed.

Quality check

• The 25th-percentile case is in the roomplans built on median-or-better velocity alone have a coin-flip's honesty; verify the pessimistic line survived into the presentation.
• The team confirmed the inputsavailability, velocity, and estimate confidence checked against the people who do the work, not just the tracker.
• Scenario C includes the dragany add-people scenario showing immediate proportional speedup is arithmetic without Brooks's Law; reject it and re-run.
• Assumptions are visible at decision timethe table goes in the deck, not the appendix; a stakeholder choosing a scenario is choosing its assumptions and should see them.
• Ranges stayed rangescheck the follow-up emails: the moment "late Oct–mid Nov" becomes "Oct 28" in someone's summary, correct it in writing.