What Is Story Point Estimation?

Reviewed by: Raúl Herranz

Story point estimation is the process of assigning story points to a product backlog item or a user story. Story points are a measurement for understanding the effort it will take to fully implement a product backlog item or user story.

A seemingly simple technique, estimation in general and story points in particular can feel abstract and frustrating in practice. To some agilists, they’re controversial for their tendency to get misused as a way to put performance pressure on a team or compare teams. 

However, with a little practice and patience, you and your scrum teammates can fine-tune a lightweight pointing process to understand the scope of the work you’re planning to do in a sprint. One way you can do this is with story point estimation.

Why Bother With Story Point Estimation?

The process of estimating work can help the developers on the scrum team forecast which product backlog items (PBIs) they plan to complete in a sprint. 

Terms to Know

Developers: Although this term sounds technology-oriented, developers are the people on the scrum team who create usable increments every sprint from a variety of industries involving complex work. It is considered an accountability distinct from the product owner or scrum master. 

Sprint: The scrum event that contains all other events. During a sprint, the scrum team commits to a sprint goal and completes work to achieve that goal. Sprints occur consecutively, one after the other. There is no gap between sprints.

Story point estimation helps developers understand whether they’re undertaking an extreme effort, a light effort, or an effort more or less equal to what they’ve historically implemented in their sprints. 

Story points also provide a metric known as velocity, which is the number of points implemented per sprint. The scrum team can use this metric internally to discuss what factors may be causing their velocity to rise or fall over time. Velocity should not be used by management or outside of the team to compare scrum teams or ask for constant upward velocity, which leads to burnout and a tendency to point PBIs as high as possible to show growth.

Estimation and Story Points Are Related to Effort, Not Hours

Instead of estimating how long a product backlog item will take to complete, the developers discuss the effort. 

Using story points or estimates that are not related to time provides a shared understanding and agreement of the effort of the work regardless of which members of the team contribute to its completion.

When a team says something like “one hour is equal to three story points,” the equivalency assumes that all members of the team will perform the same work in the same amount of time. That’s often not the case. While a senior team member may take an hour on a PBI, it may take a junior team member three times as long; however, they’ll be undertaking the same effort. Discussing effort instead of hours supports a common understanding of the scope of the work.

Pointing a story in terms of time alone is mostly an estimation of how long a PBI will take a particular individual. At that point, it’s not a holistic and universal estimation of scope.

How to Estimate Effort

Estimation, a form of understanding the size of the work, is a collaborative process in which the developers discuss the effort of completing an item from the product backlog. The question is, “If we were to implement this product backlog item fully, what is the work involved, and what is the effort of that work?”

 As part of a discussion of the effort involved, the developers may factor in the following:

• The complexity of the work
• The amount of work
• Risk and uncertainty

While the variables above are the most traditional effort-affecting variables, they are not the only ones. As a unique team in a specific domain, there could be other factors that influence how you size a PBI. 

For example, you could include the team’s skills and experience with the work involved in the PBI. If your company is new to scrum and your team isn’t yet fully cross-functional, you could include external dependencies or the need to fill in a skillset missing on the team. Whatever the variables, make sure they have meaning for your team’s estimation of effort.

By estimating the product backlog items together, the scrum team can see if certain items will involve excessive effort, in which case they may decide to break that one item down into smaller items to be tackled separately, or they may need to take on less work to accommodate the large item.

If they use an estimation metric like story points consistently over time, they can see if they’ll be working on a greater, lesser, or roughly the same number of points as they’ve worked on in previous sprints.

Story Points Are Optional

Story points are an optional tool. They are called “story points” because they’re traditionally assigned to a user story. User stories are also optional. User stories can be used to express a product backlog item as a problem statement from the perspective of the user. 

Learn more: Common questions about user stories

While many a scrum team has experienced success with story points and user stories, they are not included as a rule or guideline in the scrum framework. That doesn’t mean you shouldn’t use them. It means they are resources that can be added to your implementation of scrum. 

Scrum is a lightweight framework with the core components of team accountabilities (formerly called “roles”), events, and artifacts (the product backlog, sprint backlog, and increments). Anything outside of these core components (and a few related rules) is technically outside of the scrum framework.

Not sure if you need story points? Whether you’re a developer, product owner, or scrum master, you can propose this idea to your scrum team for feedback. Try using story point estimation if you aren’t already, then include the process as a topic for a sprint retrospective. 

Your team’s feedback and findings in the retrospective can help the developers decide if they want to continue the use of point estimation, modify it, or leave it behind. It is ultimately a developer’s tool for understanding their work and capacity, so they are the scrum team accountability who gets to decide.

When Does Story Point Estimation Occur?

Story points are one way of sizing a product backlog item. Sizing often occurs as part of the ongoing refinement activities of the scrum team. As they meet to discuss the details, information, and work involved in implementing a product backlog item, the developers may also assign sizing by way of discussion, consensus, voting, planning poker, or other methods. Developers may also size a PBI during sprint planning.

How to Do Story Point Estimation

First, it’s important to understand that the value of story points is that they are relative. The actual numerical value is meaningless. Whether you choose a scale of 1, 3, 5, or 200, 300, 400, the ratio is what matters — how the effort of a 3 compares to a 1; how the effort of 400 compares to 300. 

It’s the relativity that allows developers to compare the scope of one item to other items.

There are many different estimation techniques commonly used by agile teams. We'll discuss a few of them here as options.

There’s plenty of room to experiment. Consider trying a few different sizing methods to see which one the developers on the team agree is best.

Numerical Points, T-Shirt Sizes, Animals, Planets?

First, decide how you want to designate your relative estimation metric. It doesn’t have to be numbers. Common alternatives include the following:

• T-shirt sizes (XS, S, M, L, XL, etc.)
• An animal series (kitten, alligator, rhino — as one of many examples)
• Small to large planet series (Mercury, Mars, Venus)

Less important than the actual representation of the measurement is the relative size between the items. A product backlog item assigned a two is twice the effort of a PBI assigned a one. An alligator compared to a kitten may seem completely silly, but the team will gain a shared understanding of the relative difference between the two as they use this sizing metric over time. 

Fibonacci Sequence

It’s not uncommon to see scrum teams using a Fibonacci sequence to estimate PBIs. Here’s what the scale looks like: 

• 0, 1, 1, 2, 3, 5, 8, 13, 21, 34…
• Modified and shorter version: 1, 2, 3, 5, 8, 13, 21.

Each number is the sum of the two that came before it, although that’s not what’s important. The advantage of using this series of numbers is there’s a clearer distinction between each number.

Here’s what we mean:

When assigning a story point, a group of three developers could easily come up with a three, four, and five for a specific PBI. The numbers are quite close and less obviously distinct. On the other hand, the difference between a two, five, and an eight is more recognizable. It’s often easier to discuss the reason for the difference in points when they’re farther apart. Discussing the difference between a three, four, and five can feel like a waste of time because the numbers are so similar.

You can achieve the same thing with a sequence that doubles numbers: 1, 2, 4, 8, 16, 32.

Related Article: A Guide to Using the Fibonacci Sequence in Scrum

Agreeing to an Estimate or Size

Sizing conversations happen among the developers on the scrum team. Story points or another estimation device make it possible for everyone on the team to agree on effort through conversation. 

Insights from this conversation can be incredibly valuable. Especially when the size estimates differ widely. For example, when one developer sizes a PBI at eight and another assigns a three, a conversation ensues about why each developer chose the size. 

The ultimate outcome may be that the full scope of the work wasn’t understood by everyone. Perhaps there is some risk or complexity that only one developer recognized. Now they can align on the scope.

On the other hand, the developer who assigned a three may have recognized an opportunity. Perhaps a new tool or pivot in processes can eliminate a wasteful part of the work. The developer can explain this opportunity to the rest of the developers so they can understand it and align on the size of three.

Planning Poker and Other Methods

The whole idea is for story point estimation to be a quick, lightweight process. Determining the size to assign to a PBI shouldn’t be a laborious, painstaking task requiring hours of collaboration. 

The reason? Agile teams emphasize their interaction and collaboration over processes and tools. Don’t let this tool hamper your ability to collaborate and deliver value.

There are a few common ways scrum teams engage in a light process to estimate PBIs:

• Planning poker. Someone reads the PBI and the developers use cards with the points written on them to vote on the size of the PBI. You can hold up a card for all to see or use an anonymous version. Discrepancies are then discussed and resolved, which not only leads to a point assignment but also creates an opportunity for the team to discuss the work and get a better idea of the scope. 

• Have a discussion. The developers can simply take a few moments to discuss the PBI and agree on a point or size. Some teams don’t need anything more than a brief conversation.

• Vote, then discuss discrepancies. Take a quick vote on the size of the PBI and then hold a brief discussion to resolve any major discrepancies. 

Try different estimation techniques for a few sprints each and then evaluate those methods as a team. This way, you will find the technique that best suits your team. 

Story Points Are Not Meant to Pressure a Team to Beat Their Record

Management may be tempted to view story point completion as a performance metric. After all, it’s easy enough to look at a team’s completed story points for a sprint and see if it’s far lower or higher than previous sprints or other teams. 

Ever higher story point completion during a sprint is not the purpose of estimation. That tends to lead to employee burnout and developers inflating their estimates to prove progress. 

Story points completed from sprint to sprint can be a useful metric for the scrum team internally over time. Deviation from the team’s historical or expected velocity may indicate something meaningful. For example, are there certain parts of the team’s processes that have caused them to complete fewer story points than they expected? Were there certain changes the team made that caused them to complete far more story points than planned? Is a high number of points coinciding with one or more employee vacations or absences? Velocity can inform these conversations.

Points Could Be an Option for Sizing Your Work

Story point estimation is the process of assigning story points to a product backlog item or a user story. It helps developers understand the scope of the work they plan to do in a sprint. Story points also provide an internal team metric known as velocity, which is the number of points implemented per sprint. Estimation is a collaborative process in which developers discuss the effort of completing an item from the product backlog.

Subscribe to Agile Articles and Resources

Scrum Alliance’s Resource Library articles are meant to inspire, inform, and equip you with the knowledge you need to transform the world of work. To receive articles like this one directly, please subscribe to our emails.