Traditional software development has used hours as the unit of measure for estimating the effort for a task. Each person involved figures the hours they think their work will take, and the final estimate is the sum of the hours. This has proven to be an ineffective approach in Agile software development, however.
Story points are an estimate of complexity rather than an estimate of hours. In addition, story point estimates are a relative measure—that is, two stories with the same number of points should have approximately the same complexity and take about the same amount of effort. Story point values are restricted to Fibonacci-like numbers: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. Some of the benefits of using story points include:
Complexity removes the time efficiency bias of individuals. It is actually easier and less confrontational to agree on how complex a story is than agree on how many hours it should or shouldn’t take someone to implement it. Time estimates can have an emotional factor that results in biased estimates.
The restricted set of values for story points eliminates unnecessary overthinking on the estimates. The Fibonacci-like sequence recognizes that with more complexity comes more ambiguity on the estimate. Debating about whether a story is 12 points or 14 points becomes unnecessary.
Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time.
With story points, we know that a 5-point story is a bit more than twice as complex as a 2-point story, and that a 2-point story is twice as complex as a 1-point story. But what level of complexity does a 1-point story represent?
That answer is… it depends on the team and the nature of the project. Being at the bottom of the scale, a 1-point story should be relatively simple and easy.
One approach to helping teams determine story points is to use “anchor” or “reference” stories. These are previously estimated stories whose complexity level is well agreed upon. You can then determine if the story to be estimated is more, less, or the same complexity as the reference story.
All that said, different team members will have different perspectives on how complex a story is. For that, we need a process by which to resolve those differences to come up with a consensus estimate by the team.
Let’s proceed to estimating the points for the stories in your project backlog.