Story Points Are Not a Promise
“You said it was 5 points. Why isn’t it done yet?” If you’ve ever heard that, you already know the problem: stakeholders confuse estimates with promises.
The Confusion Is Natural
To anyone who isn’t immersed in the day-to-day of software development, an estimate sounds like a guarantee. “If the team estimated 5 points and one point equals half a day, it should’ve been done in 2.5 days.” That logic feels rational, but it’s fundamentally wrong on several levels.
Why Estimates Are Not Promises
Estimates Are Forecasts, Not Contracts
An estimate is the team’s best educated guess given the information available at the time. It’s not a commitment to perfection.
Scope Can Reveal Surprises
You only discover real complexity once you start implementing. “Oh, this table has 500 rows that need migrating” is exactly the kind of discovery that changes everything.
External Blockers
Third-party APIs going down, dependencies on other teams, shifting priorities — many factors are simply outside the team’s control.
Uncertainty Is Inherent
Software development is knowledge work, not assembly line production. If it were predictable, it would already be automated.
How to Communicate This
Use Ranges, Not Fixed Numbers
Wrong: “It’ll take 3 sprints.” Right: “Based on our current velocity, we estimate 3 to 4 sprints, with 3 being the most likely.”
Show Your Confidence Level
“For these 5 tasks we have high confidence (we’ve done similar). For these 3, medium confidence (new technology). And this one has low confidence — it could be 5 or 13 points.”
Educate Progressively
Invite stakeholders to a Sprint Review. Show them what the team ships, explain how estimation works, and demonstrate how velocity stabilizes over time.
What to Offer Instead of Promises
Predictability, Not Precision
“Over the last 4 sprints, we delivered between 22 and 26 points. We can confidently commit to 22 points for the next sprint.”
Real-Time Transparency
Share the board and the burndown chart. Stakeholders who follow daily progress are far less likely to demand hard deadlines at the end.
Options, Not Fixed Answers
“We have 3 paths: (1) reduce scope, keep the date, (2) keep scope, move the date, (3) reduce quality — I don’t recommend option 3.”
When Estimates SHOULD Be More Precise
There are situations where the margin for error needs to be tighter:
- Regulatory / compliance — legally mandated deadlines
- Fixed-date events — Black Friday, product launches
- Contracts with penalties — financial implications
In those cases:
- Add larger buffers (30-40%)
- Run technical spikes before estimating
- Communicate risks early and often
- Have a plan B
Conclusion
Story points are a planning tool, not a commitment mechanism. The role of the team and the Scrum Master is to educate stakeholders on this — using data and transparency. Trust is built through consistent predictability, not perfect promises.