480 Points, One Fixed Date, Two Unknown Epics

Give the arithmetic, a range, and a decision - not a signature.

Observed velocity: mean ~31.8, range 28-36. Twelve sprints therefore buys roughly 336-432 points, most plausibly ~380. The 40-point target is 25% above anything the team has ever achieved and is a wish, not a forecast; accepting it as a commitment converts an honest gap into a delivered-but-broken launch.

Present it as three lines and a choice:

• Capacity at current velocity: ~380 points with the team unchanged.
• Cannot fit: ~480 points (a shortfall of roughly 100 points, before accounting for the two uncertain epics, which are more likely under- than over-estimated).
• Options: cut scope to ~380; extend by about three sprints; add people (with the honest caveat that onboarding costs capacity before it adds any); or split the backlog into demo-critical versus post-launch.

The framing to use with the sponsor is that the date and the team are effectively fixed, so scope is the variable that must move - if scope, date and team are all fixed, what gives is quality, and that shows up in May, in front of the CEO.

Get the decision and the accepted risk recorded. A forecast the team believes is worth more than a commitment the team doesn't.

Buy information before buying precision.

A 90-point estimate produced in two hours for something never built is not an estimate, it is a placeholder. Carry it as a range (plausibly 60-150) and do not bury a point value in a 480-point total where it looks as solid as everything else.

• Sync engine: time-box a spike in sprint 1 - build the thinnest end-to-end slice that proves or disproves the architecture - and re-estimate from what is learned. Sequence it early precisely because it is the biggest unknown; discovering in sprint 9 that it is 150 points destroys the launch and the trust.
• Payment integration: do not schedule dependent work against a sandbox that does not exist until sprint 5. Build against a stub or the published contract, and treat the sandbox availability as an external dependency with an owner and a date, escalated outside the team.
• Dependent API teams: establish interface dates jointly and put the dependency on a shared board with named owners. Plan the team's work so it can proceed against agreed contracts rather than waiting.

Then re-forecast after the spike. That is the point of the spike - the plan is expected to change, and it should change with evidence rather than with optimism.

Plan in waves, and make re-planning routine rather than a crisis.

• Detail horizon: next two sprints in story-level detail, next two at feature level, the remainder at epic level. Elaborating 480 points up front spends effort on things that will change.
• Every sprint boundary: refresh the forecast from remaining scope and trailing velocity. Small, frequent corrections are cheaper than one dramatic one and keep the sponsor current.
• Formal checkpoint around sprints 3-4: by then the spike has run, the sandbox question is close to resolved, and there is real data. Review a burn-up chart of scope against date, confirm the demo-critical set with the sponsor, and decide go/no-go on the deferred items.
• Scope changes are shown, not absorbed: any addition appears as an upward line on the burn-up and forces an explicit trade. Silent absorption is how 'adaptive' planning becomes no planning.
• Keep a buffer for the two uncertain epics, and state that you are holding it and why.

The test of good adaptive planning here is not that the May forecast matches the February forecast. It is that no one is surprised in May, and that the team spent its learning early enough to have options.