Calculating Story Points for User Stories is not simple or straight forward since the estimates depend on the complexity, not the amount of work. Let’s explore different aspects regarding story points and then calculate story points for few examples to understand the process.
To start assigning Story Point to items in backlog, it is imperative to first decide the best sequence to use for story point values. There are two main sequences used for Story Point values: Power of Two and Fibonacci Sequence. The use of Fibonacci number in assigning story point is preferred. Since Fibonacci numbers are nonlinear and the value of a Fibonacci sequence is derived from the sum of previous two.
The Power of Two sequence is calculated based on 2^n, the sequence includes 1, 2, 4, 8, 16, 32 …
The Fibonacci sequence starts with two seed values and each subsequent number is the sum of the previous two. The sequence includes 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. The use of Fibonacci number in assigning story point is preferred since Fibonacci numbers are nonlinear.
While developing the Phonora Photo Gallery software. I used Fibonacci-like sequence for values to assign to the story points. The Fibonacci-Like Sequence is based on Fibonacci Sequence, however the numbers are rounded up or down to the nearest 10th. The sequence includes the following values: 1, 2, 3, 5, 8, 13, 20, 40, 60, 100, ...
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.
Let’s provide a Story Point estimate on the following two User Stories.
User Story 1: As a HR Manager, I want to have an employee survey with 3 fields, so that I can capture the satisfaction level of the employee categorized by each Store Location.
This User Story will involve assigning 3 points for Research Regarding the Story, 5 points for the Amount of Effort, 0 points for Complexity of Work, and 0 points for Risks and Uncertainty. The total of story points for this User Story is 8 points.
User Story 2: As a HR Manager, I want to have an employee survey with 30 fields, so that I can capture each employees’ satisfaction level categorized by Store Location, Department, and Manager.
This User Story will involve assigning 3 points for Research Regarding the Story, 13 points for the Amount of Effort, 5 points for Complexity of Work, and 0 points for Risks and Uncertainty. The total of story points for this User Story is 21 points.
It is challenging to start assigning story points from a Fibonacci scale. In order to do that each team would have to find a baseline story. The User Story does not have to be the simplest one but the one that everyone can relate. Once the baseline is set, estimation of all the user stories should be initiated by comparing them against the baseline and then adding point for each one of the four factor mentioned above.
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.