The Forecast Nobody Wanted to Compute

Forecast mechanics:

• Use delivered velocity, not committed: 31, 29, 33. Average ≈ 31; range 29–33.
• Forecast as a range, not a single number: (remaining points ÷ 33) for the optimistic case and (remaining points ÷ 29) for the pessimistic case, expressed in sprints and then dates using the sprint calendar.
• State assumptions: team composition unchanged, support load unchanged, sprint length fixed.

What the gap means:

• Committed 45/45/44 against delivered 31/29/33 is a persistent ~30% shortfall. That is not random noise and it is not primarily an estimation problem - three sprints of the same pattern points to capacity (the 40% support load removes roughly 0.8 FTE of the team's 7) and to scope instability (mid-sprint insertions displace planned work).
• Carried-over items inflate the next sprint's commitment, reproducing the problem.

Therefore: Sana should not promise a date built on the committed numbers, and should not quietly discount either. She should present the velocity-based range alongside a capacity note explaining why the historical commitment was wrong.

The judgment: The product owner owns what gets built, but the sprint goal is a commitment the whole team protects for the sprint. Mid-sprint additions are legitimate only when the sprint goal has become obsolete - not because the item is small.

Immediate response:

1. Ask what problem the new item solves and when it is genuinely needed. "Small" is a size claim, not a priority claim.
2. Offer the options: swap it for an item of comparable size (explicit trade, with the displaced item returned to the backlog), or place it in the next sprint.
3. If the sprint goal is truly invalidated, the product owner can cancel the sprint - a visible, deliberate act rather than silent scope drift.

Structural fixes:

• A definition of ready so items entering a sprint have acceptance criteria and estimates.
• Sprint backlog protection: only the team pulls work; the product owner negotiates in refinement, not during the sprint.
• Make the cost visible: track a "scope added mid-sprint" count and points, and show the correlation with missed sprint goals. Data persuades better than policy.
• Coach upward: the pressure is coming from the claims director, so the product owner needs sponsor-level air cover for saying no.

Diagnosis: "Communicate better" and "estimate more carefully" are not actions - they have no owner, no observable behavior, no measurement, and no experiment. Repeating them three times proves the retrospective is producing sentiment rather than change.

Fix - make each action an experiment:

• Specific: "Cap sprint commitment at 33 points for two sprints and measure the delivered/committed ratio."
• Owned: one named person, not "the team."
• Time-boxed: reviewed at the next retrospective.
• Small and reversible: one change at a time so the team can tell whether it worked.
• Limited to one or two per sprint - long action lists dilute follow-through.

The support load must be treated as a capacity fact, not a complaint:

• Two developers at 40% support ≈ 0.8 FTE removed from delivery every sprint. Either exclude it from capacity planning explicitly (lowering the velocity available to the product) or get a decision to staff support separately.
• Leaving it invisible guarantees that plans are built on capacity the team does not have, and it corrupts velocity data.

Escalation: Sana should surface the support-load trade-off to leadership as a decision to make - protect the release forecast or protect legacy response times - rather than absorbing it silently.