Story points: Estimation guide for user stories in Agile

Think about the last time you went on a road trip. Did it take as long as you thought it would or did you run into unexpected time-sucks, like traffic jams? Planning and estimating projects can feel a lot like that. Unexpected obstacles and project uncertainties can delay your project timeline and lead to scope creep. And, just like on your drive, you can find yourself somewhere you never expected to be—like over-budget and underperforming. 

That’s where estimation techniques come in. With estimation techniques, like story points, you can accurately scope tasks, giving you and your team a clearer picture of how much effort tasks will take and where issues might come up. Let’s dig into the benefits of story points and how to use them. 

What are story points?

Story points are a way to estimate the amount of effort required to complete a user story in your product backlog. You’ll usually estimate story points before a sprint planning meeting, since that’s when your team determines how much work they can carry out in an upcoming sprint. 

Typically, story points take into account three factors that can impact a task’s scope and effort, and the story point’s value increases accordingly. Since story points are relative, you find their value by factoring in these details and comparing similar tasks to each other.

• Risk is the amount of total risk or uncertainty associated with the task. For example, if the task involves third parties, contractors, or project stakeholders, it can increase the amount of risk.

• Repetition is the team’s experience with similar tasks. 

• Complexity is the task’s level of difficulty (and how clear the objectives of the task are). 

One important thing to know is that story points are relative—meaning that their relative value and ratios to each other are what matter, not their actual numerical value.

Story points vs. time-based estimation

You might be wondering, why not just use time as an estimate for tasks? And you’re not wrong: time-based (or hours-based) estimation is a popular way to scope work. 

But there’s a downside—unlike story points, time-based estimates don’t account for complexity, risk, or uncertainty. They also depend on each team member’s personal estimation, which can vary depending on seniority, understanding of the task, and experience with similar tasks. 

Agile story points solve these potential issues by encouraging collaboration and accounting for risk, complexity, and experience. The result is a universal scoring system that keeps team members aligned.

Six steps to implement and estimate story points

Now that you know what story points are, let’s go over how you can estimate them to scope user stories. 

1. Introduce story points to your team

A strong understanding of story points is crucial to success. To ease your team into the process, walk them through the basics and benefits of story points. In particular, make sure they understand that the story point numbers need to scale relative to each other.

Tip: Remember, ratios matter with story points, not the actual numbers. In other words, a task assigned a story point of two should take twice as much effort as a task assigned a story point of one. A task assigned a story point of three should take one and a half the amount of effort as a task assigned a story point of two. You see where we’re going with this. 

2. Determine your story point scale 

Next, determine your story point sequence. This will become the scoring method your team will use to assign story points in your estimation meeting (more on that later). Sequences are helpful because they force your team to focus on the relative size between the numbers, making estimating complex tasks easier. So, what story point sequence should you use? The Fibonacci sequence—a series of numbers where each number is the sum of the two preceding numbers—is popular for estimating in Agile. But it can get complicated. If numerical values overwhelm your team, try t-shirt sizing. As the name suggests, this sequence breaks down tasks into more manageable sizing based on t-shirt sizes: XS, S, M, L, XL, and XXL. 

Tip: When estimating in Agile, teams typically change the Fibonacci sequence to 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, and 100 for ease of use. 

3. Create a story point matrix

A story point matrix is basically a fleshed-out version of your story point sequence. It serves as a baseline for your estimation meeting and gives your team a clearer idea of how to score each task. If you haven’t used story points before, we recommend using your knowledge of the tasks your team typically completes and the complexity, uncertainty, and effort associated with them.

As you can see, story point values increase as the task’s effort, complexity, and risk increase. 

Tip: Your story point matrix will evolve as you run sprints and gain a better understanding of the effort associated with your team’s tasks. Don’t worry about making it perfect the first time—build off your team’s typical tasks and plan to re-evaluate the matrix after every sprint.

4. Hold a planning poker meeting

Now that you’ve chosen your story point sequence and created your story point matrix, it’s time to get to the meat of the matter: estimating your story points with a planning poker meeting. 

The goal of planning poker is to assign story points to user stories, get your team on the same page, and develop an idea of how many tasks your team can complete in the upcoming sprint. Planning poker does this by allowing everyone to weigh in on upcoming work. With the whole team involved, you can be sure you're assigning story points based on diverse opinions and preventing unconscious biases. 

Here’s how to run a successful planning poker meeting.    

• Give your team a defined story point matrix for reference, as well as a set of cards that depict your story point sequence. You can create the cards yourself or download a set.   

• Select a user story. 

• Discuss the story with your team, including what’s involved and what success looks like. 

• Have each team member privately select the story point card they feel represents the amount of effort required to complete the story. 

• Have your team reveal their card selections at the same time. If the story points align, move on to the next user story. If the story points don’t align, continue to discuss the user story until you reach an agreement.

• Repeat the process until you’ve assigned story points to all the tasks in your product backlog. 

• Using your story point matrix as a baseline, determine how many tasks your team can complete in the upcoming sprint.

Tip: Plan to hold planning poker sessions after your team has prioritized the backlog and before your sprint has kicked off. Planning poker sessions can take between two and four hours (and your first session is likely to take longer) so plan accordingly. 

5. Plan and execute your sprint 

If it’s your first time using story points, you won’t know exactly how many story points you can complete per sprint (also known as "sprint velocity”) until you’ve completed your first full sprint. That’s okay. In your sprint planning meeting, use your best estimation of how many story points to include in your sprint based on the complexity of tasks and the story point value. 

Tip: Your first sprint might include a high number of low-value story points, a low number of high-value story points, or a mix. Over time, you’ll learn what works best for your team and improve the process based on your team’s feedback. 

6. Continuously improve your story point estimations

Once you’ve completed your first sprint using story points, it’s time to focus on the main theme of the Agile framework: continuous improvement. To do this, get together with your team and discuss what went well and what could be improved. You can hold a separate meeting for this or include it in your sprint retrospective. 

Ask your team questions like if the story points were scoped correctly, what unexpected project bottlenecks they encountered, and the other reasons targets weren’t met. Use the answers to improve the process for the next sprint. If needed, re-evaluate your story point sequence or your story point matrix. 

Tip: Once you’ve determined your team’s velocity, use that number to distribute story points and see how many sprints it will take your team to complete an entire project.

How to use story points in Agile projects

It’s no secret: planning ahead is key to project management. Failure to properly scope and schedule out work can lead to missed deadlines, scope creep, and project failure. But if that sounds scary, don’t fret. Story points can help. 

To better understand story points, let’s take a look at how to use them within the Agile framework:

• First, write a user story for each desired feature. User stories follow the format “As a [persona], I want to [goal], so that [result or benefit].”

• Add your user stories to your product backlog. 

• Assign story points to each user story to estimate effort. 

• Use story points to select user stories from your backlog, ensuring you’re picking the right “amount” of work for each sprint. 

• Execute your sprint. 

Example: Let’s say your user story is “As a user, I want to be able to submit feedback and questions through the site to better understand product features.” You’d assign this user story a story point—again, the amount of effort you think is required to complete the story. You can then break down the story into smaller tasks, such as scoping and designing the feedback form, writing the code for the form, staging the page and testing the form, and publishing the page. 

Benefits of using story points

There’s a reason story points are the MVP of estimation techniques—they make estimating effort easier and simplify sprint planning. But that’s not all. Here are a few more benefits of using Agile story points:

• Drive faster planning. Story points are a unit of measurement for relative estimation, meaning you calculate the value of one story point by comparing it to similar, already estimated work items. Using a relative scoring method leads to faster estimation over time—a big win for your team. 

• Take unpredictability and risk into account. Agile story points account for elements like unknowns and risk. Using these factors in your planning takes the guesswork out of estimating, letting you more accurately scope effort.

• Remove skills bias from your planning and get your team on the same page. Relying on individual team member estimations isn't always best. After all, a senior team member will probably give a pretty different effort estimation than a junior team member. Story points prevent these issues by encouraging collaboration in the form of planning poker meetings. 

• Create meaningful deadlines. No one likes arbitrary deadlines, but that’s often what you get when you use other estimation techniques based on the amount of time. Since story points are more nuanced, they result in meaningful due dates.  

• Build better estimations going forward. One of the major perks of story points is that they’re adaptable and reusable. That means once you’ve created a story point matrix and held your first sprint, you can use your learnings to re-estimate your original story point values and develop more accurate estimations. 

Effective story point estimation with the product owner 

Collaborating closely with the product owner is essential for accurate story point estimation. The product owner provides valuable insights into the business value, user priorities, and acceptance criteria of each piece of work. By involving the product owner in the estimation process, Agile teams can ensure a shared understanding of the requirements and make more informed estimates.

To collaborate effectively with the product owner during story point estimation:

• Invite the product owner to estimation meetings and planning poker sessions.

• Encourage the product owner to clarify requirements, functionality, and answer questions.

• Discuss the business value and user impact of each story with the product owner.

• Ensure the product owner understands the concept of story points and relative sizing.

• Collaborate with the product owner to break down large stories into smaller, estimable chunks.

Example: Let's say the scrum team—consisting of the development team, scrum master, and product owner—is estimating a user story for a new feature in a mobile app. The product owner joins the estimation meeting and provides additional context about the feature's importance to the users and the expected functionality. The development team queries the scrum guide to clarify the acceptance criteria and edge cases. Together, the product owner and the team discuss the story's complexity and break it down into smaller, more manageable user stories. By collaborating closely with the product owner, the team gains a better understanding of the requirements and can provide more accurate story point estimates.

Avoiding common pitfalls in story point estimation

It’s not all easy in story point land. Story points streamline the project management process, but only if you avoid certain mistakes when estimating. Here are some common mistakes teams make when estimating story points—and how to avoid them. 

Using story points that aren’t relative 

The relative nature of story points makes understanding how tasks compare to each other easier for your team. That’s why you shouldn’t assign points arbitrarily. Remember: story points should scale relative to each other. 

Equating story points for hours 

Since time estimation doesn’t account for factors like complexity and uncertainty, using hour estimates or days as your story points is contrary to their goal. Instead, factor in the three components we’ve gone over—complexity, risk, and repetition—to determine your story point values. 

Inconsistent story point estimation

Inconsistency in story point estimation can lead to confusion and inaccurate planning. Ensure that your team has a shared understanding of what each story point value represents. Regular backlog refinement sessions and estimation workshops can help maintain consistency.

Overemphasis on precision 

While story point estimation aims to improve accuracy, striving for perfect precision is counterproductive. Embrace the inherent uncertainty in software development and use story points as a tool for relative sizing rather than aiming for exact estimates.

Failing to learn from past story point estimations 

Continuously improve your story point estimation by reflecting on past sprints. Compare the actual effort required to complete stories with the initial estimates. Use this feedback to calibrate your team's understanding of story points and refine your estimation process. Engage the entire scrum team, including the tester, to gather insights and metrics to improve your agile practice.

Manage sprint planning and story points with templates

Story points are an important piece of the project management puzzle. But correctly estimating effort and getting tasks to the finish line is a lot easier when your product backlog items are well organized and match your team’s work. Asana is here to help. Organize your backlog, track your Agile projects, and communicate with your team efficiently with a sprint planning template as collaborative as your team.