Story Estimation (Assigning Story Points)

To estimate the amount of work required to complete a given story (or work item), the team assign story points. Story points are an abstract value of the amount of effort required. They measure the relative difficulty of the work item when compared to other items to be developed. The difficulty includes the complexity of the work as well as the level of risk.

Story points do not directly relate to the number of hours, days, or weeks that are needed to complete the task. They are a measure of relative size. Scrum focuses on this approach of estimating work, because individuals are much better about ordering the size of stories in relationship to each other than they are at estimating the exact amount of time it takes to complete them.

To keep the focus on relative size and no a concrete measure of work (in hours, days, weeks), teams often use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) or t-shirt sizing (X-Small, Small, Medium, Large, Extra-Large). These measurement values are not linear and make it easier to use for comparisons. In the case of the Fibonacci sequence, the difference between something that is a “8” vs. a “2” is easier to establish than perhaps the difference between a “5” and a “6”.

Before assigning story points to user stories, your team should establish the size of a reference story. This story becomes the basis for estimating other stories. For example, if everyone agrees that the size of adding several new filters on your website to allow users to narrow the list of shoes that display in a product search is a “3” in the Fibonacci sequence or “medium” in t-shirt sizing, they can use this story as a reference to size other stories for the sprint. Is the new user story bigger or smaller than creating filters? If it is bigger, is it just a little bigger or twice as big?

Once the team has a good understanding of the size of reference story, story pointing can begin. The product owner pulls items from the product backlog that are good candidates for inclusion in the next sprint. The team discusses each user story briefly, so that everyone on the team has an understanding of the work involved to complete that story.

Each member votes on the size of the first user story using pointing cards, pointing apps, or use hand signals—whatever works for your team. Voting should happen simultaneously to prevent team members from being influenced by each other’s votes. If the team agrees on the size of the user story, you record that value and then move on to size the next story. If the team does not agree, team members need to discuss the user story (and why they chose the size that they did) in order to come to a consensus on the size. Team members should feel comfortable justifying their position, even if the rest of the team disagrees initially. Pointing user stories is a collaborative effort. Team members should come with opinions on the sizes of stories but be willing to listen to others as they explain their position. The scrum master facilitates the backlog refinement sessions—ensuring that team members respect each other and the team rules that they have set for themselves.

The number of story points that a team finishes in a single sprint is known as the team’s velocity. After a few sprints, you will get a better understanding about the amount of work your team can complete in a sprint. In the meantime, do not be concerned if you under or overestimate the number of points that your team can complete. Your team will get better at estimating tasks as you gain experience.