Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.
When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant: Some teams use a modified fibonacci sequence (1, 2, 3, 5, 8, 13); others use a doubling sequence (1, 2, 4, 8, 16).
What matters are the relative values. A user story that is assigned two story points should be twice as much effort as a one-point story. It should also be two-thirds the effort of a story that is estimated as three story points.
Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers.
One of the main reasons story points are so valuable is that they allow team members with different skill levels to communicate about and agree on an estimate. Instead of arguing about how long it might take each team member personally to do something, teams instead can quickly say that this user story is about twice or three times as much effort as that user story. With story points, it’s all relative.
How to Calculate Story Points in Agile
The best definition of story points is that they represent the effort to develop a user story or product backlog item.
Effort is a question of time: how long it will take to finish something. Many factors go into determining effort, including
- The amount of work to do
- The complexity of the work
- Any risk or uncertainty in doing the work
When estimating with story points, many things come into play: complexity, effort, risk, and volume. But ultimately, story points are an estimate of effort.
Let’s see how each factor impacts the effort estimate given by story points. For each factor that goes into choosing story points, examples are provided to help increase understanding.
The Amount of Work to Do
Certainly, if there is more to do of something, the estimate of effort should be larger. Consider the case of developing two web pages. The first page has only one field and a label asking to enter a name. The second page has 100 fields to also simply be filled with a bit of text.
The second page is no more complex. There are no interactions among the fields and each is nothing more than a bit of text. There’s no additional risk on the second page. The only difference between these two pages is that there is more to do on the second page.
The second page should be given more story points. It probably doesn’t get 100 times more points even though there are 100 times as many fields. There are, after all, economies of scale and maybe making the second page is only 2 or 3 or 10 times as much effort as the first page.
Risk and Uncertainty
The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item.
If a team is asked to estimate a product backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate.
If implementing a feature involves changing a particular piece of old, brittle code that has no automated tests in place, that risk should be reflected in the estimate.
Complexity
Complexity should also be considered when providing a story point estimate. Think back to the earlier example of developing a web page with 100 trivial text fields with no interactions between them.
Now think about another web page also with 100 fields. But some are date fields with calendar widgets that pop up. Some are formatted text fields like phone numbers or Social Security numbers. Other fields do checksum validations as with credit card numbers.
This screen also requires interactions between fields. If the user enters a Visa card, a three-digit CVV field is shown. But if the user enters an American Express card, a four-digit CVV field is shown.
Even though there are still 100 fields on this screen, these fields are harder to implement. They’re more complex. They’ll take more time. There’s more chance the developer will make a mistake and be required to back up and correct it.
This additional complexity should be reflected in the estimate provided.
Consider All Factors: Amount of Work, Risk and Uncertainty, and Complexity
It may seem impossible to combine three factors into one number and provide that as an estimate to take to sprint planning. It’s possible, though, because effort is the unifying factor.
First, Scrum team members consider how much effort will be required to do the amount of work described by a product backlog item.
Next, these agile teams consider how much effort to include for dealing with the risk and uncertainty inherent in the product backlog item. Usually this is done by considering the risk of a problem occurring and the impact if the risk does occur. So, for example, more will be included in the estimate for a time-consuming risk that is likely to occur than for a minor and unlikely risk.
Finally, teams must also consider the complexity of the work to be done. Work that is complex will require more thinking, may require more trial-and-error experimentation, perhaps more back-and-forth with a customer, may take longer to validate and may need more time for mistake corrections.
During agile estimation, all three factors must be combined into one measure of effort.
Remember the Definition of Done
A story point estimate must include everything involved in getting a product backlog item all the way to done. If a team’s definition of done includes creating automated tests to validate the story (and that would be a good idea), the effort to create those tests should be included in the story point estimate.
Scrum, Story Points, and Conversations
Conversations are an essential component of agile estimating. Even with thought exercises like story points as buckets, team members often don’t agree at first on how much effort a story will be.
These varying estimates can spark illuminating conversations between team members and with product owners about acceptance criteria/conditions of satisfaction, approach, and other factors that can affect how much effort it will take to complete an item. Talking about a product backlog item increases the team’s understanding of the work, and can reveal gaps and assumptions that the product owner can investigate.
The power of these conversations is one of the reasons I recommend planning poker. Planning poker is a fun way to estimate, and it’s also a way to keep each person’s estimate private until the team members all reveal their cards. Individual estimates mean less bias in the numbers and, ultimately, estimates that are more accurate.
Once the team has agreed on an estimate, it assigns story points to the backlog item. That story point estimate is later used in calculating a team’s average sprint velocity, capacity, and more.
Story points can be a hard concept to grasp. But the effort to fully understand that points represent effort—as impacted by the amount of work, the complexity of the work and any risk or uncertainty in the work—will be worth it.
