Story Points and Relative Estimation Clarified
Understand story points and relative estimation in Scrum. Learn why they are used, how they work, and their practical application for Product Backlog management and forecasting.
Many teams use story points for estimating work on the Product Backlog. This practice often causes confusion. Story points are not about time. They are a measure of the relative size of work. The Scrum Guide does not mandate their use. It states that Product Backlog items have an attribute of size. Story points are one way to represent that size. The purpose is to help the Scrum Team forecast what can be done.
What is Relative Estimation?
Relative estimation means comparing one item to another. Instead of guessing how many hours a task will take, you decide if it is bigger or smaller than a known task. For example, if adding a new user profile field is a 'small' task, then integrating with a payment gateway is probably a 'large' task. This avoids the trap of false precision that comes with hourly estimates. Humans are better at relative sizing than absolute sizing.
Why Not Estimate in Hours?
Estimating in hours is often inaccurate. Developers are not always working at full capacity. Interruptions, unexpected complexities, and learning new things all affect actual time spent. An estimate of 8 hours might become 16 hours or 4 hours. This variability makes planning difficult and creates false expectations. Hours also imply a specific person doing the work, which conflicts with the Scrum Team's collective accountability.
Story points abstract away these problems. They represent the effort involved. This effort includes complexity, risk, and volume of work. A team assigns points based on their collective understanding, not individual speed. This fosters collaboration and shared responsibility.
How Story Points Work
Teams typically use a modified Fibonacci sequence for story points: 1, 2, 3, 5, 8, 13, 21. The increasing gaps between numbers reflect the increasing uncertainty as items get larger. Here is a simple process:
- Establish a baseline: The team picks a small, well-understood Product Backlog Item (PBI) and assigns it a low point value, like 2 or 3.
- Compare new items: For each new PBI, the team discusses it and compares it to the baseline and other previously estimated items.
- Assign points: Through discussion or techniques like Planning Poker, the team collectively agrees on a point value. If an item is too large (e.g., 21 points or more), it should be broken down.
- Refine understanding: The discussion during estimation helps clarify the PBI, uncover assumptions, and identify dependencies. This is a primary benefit.
Velocity and Forecasting
Over several Sprints, a Scrum Team will complete a certain number of story points. This average is called 'velocity'. Velocity is a team-specific measure. It should not be used to compare teams. Its value is for the team to forecast how many Product Backlog Items they might complete in future Sprints. For example, if a team consistently completes around 20 points per Sprint, they can use this to inform Sprint Planning and release forecasting.
Velocity is a tool for the Scrum Team. It helps with planning and transparency. It is not a performance metric for individuals. Focusing on increasing velocity can lead to bad behaviors, like inflating estimates or neglecting quality. The goal is to deliver valuable increments, not to hit a point target.
Conclusion
Story points and relative estimation are useful tools for Scrum Teams to manage their Product Backlog. They promote shared understanding and provide a basis for forecasting. Remember, they are a means to an end: delivering valuable, working software. Focus on the conversations and the learning that happens during estimation, not just the numbers themselves.