Story Points and Relative Estimation: A Practical Guide
Understand story points and relative estimation in Scrum. Learn why comparing work items to each other, not time, improves planning and team collaboration.
Many Scrum Teams use story points for estimating the effort of Product Backlog Items. This practice is about relative estimation. It is not about predicting exact hours or days. Instead, it asks teams to compare one piece of work to another. This approach helps the Scrum Team make better decisions and understand the complexity involved.
What is Relative Estimation?
Relative estimation means sizing items in comparison to each other, rather than assigning an absolute measure like hours. Think of it like comparing the size of different animals. You might say a cat is bigger than a mouse but smaller than a dog. You are not measuring their exact weight or height. You are using a known reference point to estimate others. In Scrum, this reference point is typically a small, well-understood Product Backlog Item that the team has already done or is confident they can do quickly.
The Developers are responsible for these estimates. They are the ones who will do the work. Their collective understanding of the work is what matters most. The Product Owner ensures the Product Backlog Items are clear and understood, but the Developers provide the estimates.
Why Not Estimate in Hours?
Estimating in hours often leads to problems. People are bad at predicting the future. Hours can imply a commitment that is hard to meet due to unforeseen complexities, dependencies, or interruptions. It can also create pressure to work longer hours to meet an arbitrary time estimate. Relative estimation moves the focus from time to complexity, effort, and uncertainty. This is a more honest way to look at work.
Furthermore, hours are not consistent across individuals. A task that takes one developer two hours might take another four hours. Story points abstract away these individual differences, focusing on the inherent size of the work itself for the team as a whole.
Story Points: The Unit of Measure
Story points are an abstract unit. They represent the overall effort required to implement a Product Backlog Item. This effort includes:
- Complexity of the task.
- Amount of work involved.
- Risk or uncertainty associated with the task.
Commonly, teams use a modified Fibonacci sequence for story points: 1, 2, 3, 5, 8, 13, 21. The gaps between numbers grow larger. This reflects the increasing uncertainty and difficulty in estimating larger items. A 13-point item is not just twice a 5-point item. It is significantly more complex and less predictable.
How to Conduct Relative Estimation
Teams often use a technique called Planning Poker. Each Developer gets a set of cards with the Fibonacci sequence. The Product Owner presents a Product Backlog Item. Developers discuss it to ensure shared understanding. Then, each Developer privately chooses a card representing their estimate. On a count, all cards are revealed simultaneously. If estimates vary widely, the Developers with the highest and lowest estimates explain their reasoning. This discussion helps uncover assumptions and clarify details. The team then re-estimates until a consensus is reached or a reasonable average is accepted.
The goal is not perfect accuracy. It is about building a shared understanding of the work. This process helps identify unknowns and encourages collaboration among the Developers. It is an act of refinement, not just an assignment of numbers.
Velocity and Forecasting
Over time, as a Scrum Team completes Sprints, they will establish a consistent velocity. Velocity is the sum of story points for all Product Backlog Items successfully completed in a Sprint. This historical data helps the team forecast how much work they can realistically pull into future Sprints. It is a tool for planning, not a performance metric for individuals.
A stable velocity allows the team to make informed predictions about when larger sets of work might be done. However, velocity can fluctuate. New team members, changes in technology, or external dependencies can all impact it. The team inspects and adapts its understanding of its velocity regularly.