Story points in Agile: how to estimate user stories

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.

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 they will take and where issues might arise. Let's dig into the benefits of story points and how to use them.

What are story points?

Story points are units of measurement used in Agile to estimate the overall effort required to complete a product backlog item. Unlike hour-based estimates, story points account for task complexity, risk, and uncertainty, making them a more reliable way to scope work. Teams typically assign story points before a sprint planning meeting to determine how much work fits in an upcoming sprint.

Typically, story points account for 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: their relative value and ratios to each other matter, not their actual numerical value. Mike Cohn, founder of Mountain Goat Software and author of Agile Estimating and Planning, popularized Agile story points as part of the Agile framework.

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 estimate, which can vary by 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.

Why use story points instead of hours?

You might wonder why teams don't just estimate work in hours. While time-based estimates are common, they often miss the full picture. An hour for a senior developer isn't the same as an hour for a junior developer, and this approach doesn't account for unexpected roadblocks or complexity.

Story points solve this by focusing on relative effort, not time. Instead of debating whether a task will take four hours or six, the team agrees on its size relative to other tasks. This shifts the conversation from "How long will this take you?" to "How big is this for us?"

6 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. 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 1.5 times the effort of a task assigned a story point of two.

2. Determine your story point scale

Next, determine your story point sequence. This scoring method forces your team to focus on relative size between numbers, making complex task estimation easier.

Common story point scales include:

• Modified Fibonacci sequence: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. The gaps between numbers grow larger, reflecting increased uncertainty with bigger tasks.

• T-shirt sizing: XS, S, M, L, XL, XXL. A simpler alternative if numerical values overwhelm your team. Learn more about t-shirt sizing.

3. Create a story point matrix

A story point matrix expands your sequence into a reference guide that defines what each point value represents. It serves as a baseline for estimation meetings and helps your team score tasks consistently. If you're new to story points, start by mapping your team's typical tasks to levels of complexity, uncertainty, and effort.

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 gauge 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 believe best represents the effort required to complete the story.

• Have your team reveal their card selections simultaneously. If the story points align, move on to the next user story. If the story points don't align, continue discussing 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 complete 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 OK. In your sprint planning meeting, use your best estimation of how many story points to include in your sprint backlog 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 of both. 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 whether 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.

Use your findings to estimate sprint velocity, the number of story points your team can complete in any given sprint. For example, if your team completes 4 story points per day, your sprint velocity is 40 story points over a 2-week sprint.

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 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.

• Complete your sprint.

Example: Your user story is "As a user, I want to submit feedback through the site to better understand product features." You'd assign this story a point value based on total effort, then break it into smaller tasks:

• Scope and design the feedback form

• Write the code for the form

• Stage the page and test the form

• Publish 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. 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.

• 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 members' estimates isn't always the best. Story points help prevent these issues by encouraging collaboration through 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 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. Once you've created a story point matrix and held your first sprint, you can use your learnings to 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: A scrum team is estimating a user story for a new mobile app feature. The product owner joins the estimation meeting, clarifies acceptance criteria, and provides context about the feature's importance to users. Together, they discuss complexity and break the story into smaller, more manageable pieces, resulting in more accurate 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 it easier for your team to understand how tasks compare with each other. 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 estimates don't account for factors like complexity and uncertainty, using hour estimates or days as 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.

Manage sprint planning and story points with Asana

Story points are an important piece of the project management puzzle. But correctly estimating effort and getting tasks to the finish line is much easier when your product backlog items are well organized and align with 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. Ready to streamline your sprint planning? Get started with Asana today.

Frequently asked questions about story points