Sprint Variance Was 60%. The Fix Wasn't Better Estimation.

Estimation was never the broken part

The instinct when sprints miss is to fix the numbers. Re-point the stories, add a buffer, introduce a fancier scale. I've watched teams spend hours refining estimates on work whose requirements would change three days later, which is a very organised way to be wrong.

Variance that high isn't an arithmetic problem. It's a signal that work is entering the sprint before it's actually understood, and that unplanned work is entering after the sprint starts. Those are the two real causes and neither is solved by a better Fibonacci sequence.

Cause one: stories that were still questions

A lot of what we called a "story" was a question with a story template around it. Nobody had confirmed the licensing edge case, or which customer segment it applied to, or whether Support had a workaround already. Engineering would start, hit the ambiguity, and stop. That gap is invisible in the estimate and enormous in the actual.

The fix was boring: nothing enters a sprint unless the acceptance criteria can be read by someone outside the team and understood without a conversation. If it needs the conversation, it's a discovery item, not a delivery item, and it gets its own slot. Sprints got noticeably emptier, and then noticeably more predictable.

Cause two: P1s eating the plan

The other half was incident work. Critical enterprise issues would land mid-sprint and quietly consume whatever capacity the plan assumed it had. You can't schedule those away, but you can stop pretending they don't exist.

We built explicit capacity for incident response and hotfix delivery instead of treating every P1 as an exception. Counterintuitively, taking the interruption seriously made both sides better: SLA adherence went to 100% and P1 resolution went from weeks to days, while the planned work stopped getting silently robbed.

The lesson generalises. Any recurring interruption you refuse to put in the plan will take its capacity anyway, and it will take it from whatever you least wanted it to.

Predictability is a product feature

I care about variance for a reason that isn't process hygiene. When you own $62M of SaaS products across a complex enterprise environment, delivery dates are commitments made to customers by Sales, and to auditors by compliance. A team that hits 100% on-time delivery for its major releases isn't just tidier, it earns the right to be believed the next time it says a date.

That trust is what lets you take a real bet later. Nobody funds an ambitious roadmap from a team whose last four sprints were a rounding error away from fiction.

The uncomfortable summary

Better predictability came from committing to less, writing requirements that survive contact with an engineer, and admitting what actually interrupts the team. There's no framework in that, which is probably why it took a while to get around to it.