There are many reasons why Scrum teams use story points to estimate user stories. In the 1940s, the Rand Corporation conducted a study that measured the effectiveness of estimation techniques. The conclusion was that humans are poor estimators of the amount of time it will take them to accomplish planned work. This is due to several factors including optimism bias and the planning fallacy which makes us think we can accomplish more in less time than we are physically capable of doing.
The study uncovered that we are good at comparing user stories against each other and determining if they are bigger, smaller, or the same size. The comparison of stories is commonly referred to as relative sizing. The only time relative sizing was less accurate than hours estimation was when subject matter experts openly expressed their opinion about the size of an item before everyone had voted, resulting in a bias across the group.
Bias is one of the main reasons why the consensus-based, estimation game “planning poker” is commonly used by Scrum teams to estimate user stories. Planning poker allows team members to relatively size new work against past work. Fibonacci numbers are typically used as card numbers when playing Planning Poker because the exponential growth of the numbers provides a rapid spread which makes relative sizing easier.
To play the game, the Product Owner explains the details of the story in great detail ensuring all team members understand what it takes to be done. Development Team Members select a planning poker card from the Fibonacci number sequence that best reflects their current understanding of the complexity, thought, effort, risks, unknowns, and dependencies associated with the new user story in comparison with a user story they completed in the past.
By hiding each person’s planning poker card numbers and exposing them at the same time, bias is eliminated and those with differing opinions can gain a shared sense of understanding through discussion. This aids in focusing the conversation on the areas where there is a difference in opinion. The team’s story points are typically averaged unless they are outside of three Fibonacci numbers. In that case, the team member with the highest and the team member with the lowest number explains their reasoning.
A good practice for your Scrum teams is to create a reference library where the value of a story point is captured. This will prevent point inflation in the future and help you better measure the creative ways that your teams are automating, improving processes, and removing waste so that they can achieve more in the same amount of effort.
One thing to note in the above scenario is that hours never went away. Instead, hour estimation became an output, not an input. Let me explain that concept further, teams work in sprints or timeboxes that are fixed periods of time. An example of this would be 1-4 week sprints. During that sprint, team members are only capable of working a set number of hours which result in a certain number of completed story points. The number of completed story points in a Sprint is often referred to as a team’s velocity. When teams estimate in story points the output is that you can now calculate when that work will be complete and how much it will cost based on their current velocity.
When teams think about the categories of relative sizing and compare new work against work they have done in the past, their estimates are more accurate and complete.
View our YouTube video on the basics of estimating > https://youtu.be/C8uw9vaEo1o