Who Should Estimate Story Points? Understanding Agile Best Practices
I came across the following question on the Atlassian community forums:
Are story points estimated by the product owner or the development team?
The short answer is the development team. Why? Because the development team is the most knowledgeable about the work at hand, have the best insights into what needs to be done and the effort it takes.
Should the Product Owner or the Scrum master provide estimates?
It only makes sense for a Product Owner or Scrum Master to provide estimates if they have a deep understanding of the codebase. Without that knowledge, they lack insight into the actual effort required to build the software.
A meaningful estimate requires knowing what needs to change, where the uncertainty lies, and how the change affects the existing codebase. Without that knowledge, there's nothing solid to base an estimate on — it's just a guess disconnected from the actual work.
From my own experience, when working as a Product Owner or Scrum Master, I have never provided estimates—simply because these roles demand full focus on other responsibilities, leaving no bandwidth to stay deeply involved in the codebase.
What’s Wrong with Estimating Without Being on the Development Team?
The reason only the development team should provide estimates is simple: they have the best understanding of the codebase and the work required to implement a story.
When someone outside the team — such as a Product Owner or Scrum Master — provides an estimate, it lacks technical insight. They don't have firsthand knowledge of the current state of the codebase, dependencies, or potential complexities. As a result, their estimates are often inaccurate, leading to unrealistic expectations and poor planning.
Worse, when a non-developer shares an estimate before the team does, it creates an anchoring effect. The team's thinking gets pulled toward that number — even if it's wrong. This is exactly why Planning Poker reveals all estimates simultaneously: to prevent any single voice from anchoring the group.
Estimate gain value when made by the people doing the work.
Why Would Someone Outside the Dev Team Want to Give an Estimate?
Why would someone who isn't on the development team — and has less knowledge about the actual work — want to provide an estimate? There are a few possible reasons:
- They genuinely believe the work can be completed in less time.
- They think the estimated effort is too high compared to the value the feature delivers.
- They want to influence the team to lower their estimate—a classic example of anchoring bias.
- They aim to negotiate a "better" estimate to fit within a specific timeline or expectation.
In cases 1 and 2, the stakeholder may have a legitimate perspective worth discussing. Walk them through why the estimated effort is what it is, which parts require the most time, where the biggest unknowns or risks are, and how scope could be reduced to lower the effort honestly.
In cases 3 and 4, the stakeholder is trying to shrink the estimate to fit a desired timeline — and that's a path toward unrealistic expectations and project failures. Pushing for a lower dev estimate is like negotiating better weather with a meteorologist'. The estimate reflects expected time the work takes, not a negotiating position.
