Story Points and Relative Estimation Clarified
Understand story points and relative estimation in Scrum. Learn why teams use them, how they work, and their benefits for planning and forecasting, explained clearly.
Many Scrum teams use story points for estimating the effort to complete Product Backlog Items. This practice, called relative estimation, helps teams plan their work without getting bogged down in precise time commitments. It is not a Scrum Guide requirement, but a widely adopted technique that supports empiricism and self-managing teams. The goal is to understand the size of work relative to other work, not to predict exact hours or days.
What is Relative Estimation?
Relative estimation means comparing one item of work to another. Instead of saying 'this will take 8 hours,' a team might say 'this is twice as big as that other thing we did.' This approach acknowledges that predicting exact time for complex, novel work is difficult and often inaccurate. By focusing on relative size, teams can make more consistent judgments. It shifts the focus from duration to perceived effort, complexity, and risk.
Why Story Points?
Story points are abstract units. They are not tied to hours or days. This abstraction helps avoid the common trap of converting estimates into fixed deadlines, which often leads to pressure and inaccurate forecasts. Story points encourage discussion among Developers about the work involved, leading to a shared understanding. When a team assigns story points, they consider factors like:
- Effort required to complete the item.
- Complexity of the item.
- Uncertainty or risk involved.
- Dependencies on other systems or teams.
The Scrum Guide states that Developers are responsible for creating a plan for the Sprint, which includes selecting and estimating Product Backlog Items. Story points support this without requiring the Product Owner to dictate how the work should be done. It is the Developers who are best placed to estimate the work.
How Teams Use Story Points
Typically, a team establishes a baseline. They pick a small, well understood Product Backlog Item and assign it a low point value, say 1 or 2. Then, all other items are estimated in relation to this baseline. Common sequences for point values include the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21...) or a simplified version. This non-linear scale reflects the increasing uncertainty that comes with larger items; a 13 is not just three 5s, but implies greater unknowns.
During Product Backlog Refinement, Developers discuss items and assign points. If there is wide disagreement, it signals different understandings of the work, prompting further discussion. This process builds shared knowledge and a common definition of 'done' for the item. The Product Owner ensures the Product Backlog is transparent, understood, and refined, but the estimation of effort is the Developers' responsibility.
Velocity and Forecasting
After a few Sprints, the team's 'velocity' emerges. Velocity is the sum of story points for all Product Backlog Items successfully completed in a Sprint. This is an empirical measure. It is a historical average that helps the team forecast how much work they can realistically pull into future Sprints. It is a tool for the Developers to manage their own capacity and for the Product Owner to make informed decisions about future product development. Velocity is a team measure, not an individual one, and it should not be used to compare teams or individuals.
The Product Owner can use velocity to forecast when a larger chunk of work might be done, based on the total points remaining in the Product Backlog. This is a forecast, not a guarantee. The Scrum Team continuously inspects and adapts this forecast as more is learned. The key is transparency and frequent adjustment.
Common Pitfalls to Avoid
Do not treat story points as a measure of productivity for individuals. This undermines team collaboration and transparency. Do not convert story points to hours. This defeats the purpose of relative estimation and reintroduces the problems of time-based estimating. Story points are a communication tool for the Developers, to help them understand and plan their work, and for the Product Owner to forecast. They are not a contract or a performance metric.