How to Calculate Story Points for a User Story in Agile

While developing Phonora Photo Galley, I soon figured out that when assigning story points, it is not just the amount of work that should be accounted for but also everything that goes along with development of the story including Research Regarding the Story, Amount of Effort, Complexity of Work, and Risks and Uncertainty.

So, let’s visit each one of these factors and develop story points for some user stories to visualize the best way to calculate story points.

Research Regarding the Story

Any research effort required to develop a User Story should be accounted for in the story points. For example, the requirement includes building an anonymous employee survey with three fields: Department, Employee Satisfaction Level with values (Terrible, Poor, Neutral, Good, Excellent), and Store Locator with values populated from list of all stores the company owns. The developer might need to contact the database team to find out whether there is a list of all stores available to use in development effort and how to access this list.

The Amount of Effort

Work involving higher complexity will obviously have more work effort involved. However, most of the time amount of work effort involved is nonlinear. For example, the stakeholder wants to create two surveys. The first survey only has three fields and the second survey has 30 fields. The second survey with 30 fields are additional simple questions about employees’ satisfaction level and areas of improvement.

The second survey is no more complex as compared to the first survey. There are no additional risks or research involved with the second survey. The only difference between the two surveys is the amount of work involved.

The first survey is assigned 5 story points. The second survey is assigned more story points, however, not 10 times more even though there are 10 times more fields required on the second survey. The work effort involved depends on the scale, which for example would make the second survey only 2 to 3 times more work effort required as the first survey.

Complexity of Work

Complexity is one of the most important aspects to consider when providing a story point estimate. If the survey has simple 30 questions, the complexity is going to be much lower than a survey with questions that depend on each other. For example, when an employee chooses a department they work for, the manager section should allow the employee to select their manager anonymously. This feature will also provide feedback on manager level by linking the answers of the employees to a specific manager.

Even though there are still 30 fields in the survey, the latter is harder to implement and involves more complexity. Work that is more complex requires more time even though the amount of work seems the same. The addition of complexity should reflect in estimating Story Points.

Risk and Uncertainty

The amount of risk and uncertainty in a product backlog item should affect the story point estimate assigned to the item. If the stakeholder is requesting a feature, however the team does not fully know how it will affect other aspects of the software, the uncertainty should be reflected in the estimate. If implementing a feature involves changing code shared by other aspects of the software, that risk should reflect in the estimate as well.

Combining these four factors into one number to provide an estimate on Story Points seems challenging. However, it is possible by simply adding work effort required for each factor because effort is a unifying factor. This is why Story Points are based on how much effort will be required to complete a work item in product backlog.

In order to manage story points in a Sprint, depending on the resources, first calculate the amount of total Story Point that can be completed in a Sprint. Based on the priority and dependency, assign user stories to a Sprint totaling up to 90% capacity of the Scrum team. I always reserve 10% of team resources to accommodate bugs and errors.

I noticed that while working on current sprints, a number of times bugs and errors surface regarding functionality built in previous sprints. These bugs and errors were simply missed by QA to capture in that sprint. I would not calculate story point for bugs to include in current sprint since they really do not belong to the current sprint. This is the reason why I started reserving 10% resources to accommodate bugs.

Now instead of emphasizing on calculating the amount of hours required to complete a user story, the emphasis should be on estimating the time remaining to complete all User Stories in a Sprint. For example, a Scrum team has the capacity to complete 100 story points in a Sprint lasting 2 weeks. This calculation can be displayed in a graphical manner using Burn Down Chart. This representation gives a good estimate on whether the tasks are on schedule and will be completed within the current Sprint.