User story points: What are they and how can we use them?

Story points are an important part of user story mapping, and most agile teams use them when planning their work out each sprint.

But if you’re new to using story points, they can be a little confusing. They’re not as simple as adding numbers to tasks or estimating how much time a job will take.

Even if you’ve been using story points for a while, you’ll find that different teams and organizations will use them in different way.

So, let’s define story points, discuss why they’re so useful for agile teams, and talk about some of the different ways teams implement them in story mapping and sprint planning.

What are user story points?

Story points are a useful unit of measurement in agile, and an important part of the user story mapping process. A number is assigned to each story to estimate the total effort involved in bringing a feature or functionality to life.

By the way, if you’re not sure what user story mapping is, check out our ultimate guide to user story mapping!

When to estimate story points

Story points are usually estimated during user story mapping.

After product owners have defined user stories, mapped them to the backbone, and prioritized them, it's time to estimate the story points. The team works together to do this, as each team member plays a different role in different stories, and knows the work involved in UX, design, development, testing, and launching, as well as different dependencies.

You need to assign story points to each story before you can organize the stories vertically into releases or sprints. That's because your team will have a limited timeframe to complete the stories assigned to each release, and usually two-weeks to complete a sprint.

So, you have to carefully consider how much work and effort is involved in each story, and make sure that your team has the capacity to deliver on the work they've committed to.

How to estimate user story points

When calculating story points, you're looking at the total effort involved in making that feature or functionality live so that it can deliver value to the customer. Your team will need to discuss questions like:

• How complex is the work?
• How much work is needed?
• What are the technical abilities of the team?
• What are the risks?
• What parts are we unsure about?
• What do we need in place before we can start or finish?
• What could go wrong?

Tip: If you're having trouble estimating a story or the scope of work is overwhelming, your story might need breaking down into smaller parts, and you may need to split it up across multiple stories.

What is each story point “worth”?

This is where story points can get a little confusing, as story points don’t have a set universal value. You kind of have to figure out what they’re worth to you and your team (yep, real deep and meaningful stuff).

Here’s how it works:

-Each story is assigned a certain number of story points

-Points will mean different things to different teams or organizations

-1 story point for your team might not equal the same amount of effort involved in 1 story point for another team

-The amount of effort involved in 1 story point should remain stable for your team each sprint and it should remain stable from one story to another

-2 story points should equal double the effort compared to 1 story point

-3 story points should equal triple the effort compared to 1 story point… and so on

-The number you assign doesn't matter - what matters is the ratio. The story points should help you demonstrate relative effort between each story and each sprint

Estimating story points for the first time

Because story points are relative, you need to give yourself some baseline estimates for the first time you do story point estimation. This will give you a frame of reference for all future stories.

Start by choosing stories of several different sizes:

• One very small story
• One medium sized story
• One big story

...a bit like t-shirt sizes.

Then assign points to each of these baseline stories. Your smallest story might be 1. If your medium story requires 3 times more effort, then it should be 3. If your big story requires 10 times the effort, it should be 10. These numbers will depend on the type of stories your team normally works on, so your baseline story numbers might look different to these.

The important thing is that you’ll be able to use these baseline stories to estimate all your future stories by comparing the relative amount of effort involved.

Using the Fibonnaci sequence for story point estimation

Some teams use the fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.) for their story point estimates, rather than staying linear or allowing teams to use any number (1, 2, 3, 4, 5, 6, 7, etc.).

This has its benefits. For example, if you're looking at a story and trying to estimate whether it's a 5, 8, or 13, it's much quicker and easier to come up with an answer than trying to land on the right number between, say, 4-15. You'll likely reach consensus much more quickly.

This also means you won't be able to average the team's story points to finalize the estimation. Instead, you'll need to discuss the work and decide on the best estimate from a limited set of options.

But it does limit your options - if you have a story that’s more effort than 34, but less than 55, your estimate might be less accurate.

Using story points to estimate your team's velocity

After some time working together most teams will have a good idea about how much effort is involved in each story point.

Of course, timing isn't exact - there's a bell curve, and story points are designed to be an estimate of effort, not time.

But story points (and knowing their approximate timing) can be useful when it comes to figuring out how much your team can get done each sprint.

You should be able to estimate about as many story points your team can manage during a two-week sprint, or whatever timeframe you’re working to.

For example, if your team can usually get through 3 story points per day, this might add up to 30 story points across a two-week sprint. This is your velocity.

Velocity is useful for user story mapping and sprint planning. When mapping your user stories to sprints or versions, you can check the total story points and make sure it matches up with your velocity so you’re not over- or under-committed.

As you can see there are a few different methods for estimating work. The best advice is to be conservative and not overload the team.

Over time, your estimations should become more accurate.