What Are Story Points and How Do You Use Them?

Are you tired of struggling with task estimation? Do you find story points confusing and frustrating, even though they seem like a great idea in theory?

Story points can be tricky to understand and use effectively. Even when you think you’ve got the hang of it, you can feel stuck in a loop of confusion because there are so many ways to misuse them. And if that wasn’t bad enough, management sometimes turns story points into performance metrics, putting even more pressure on teams.

This complete guide addresses these and other issues with story points. We’ll cover everything you need to know, so you can finally use them correctly and get the value they’ve always promised to deliver.

Here’s what we’ll cover:

Story points are a relative measure of the effort and complexity required to complete a task or user story in agile software development. They’re usually expressed as a number. 

The concept of story points was originally developed by Ron Jeffries as part of the Extreme Programming (XP) agile framework. But they have since come to be used by teams that use other frameworks, like Scrum.

With story points, rather than estimating how long a task will take, team members assign a number of points based on factors such as the complexity of the task, the level of uncertainty or risk involved, and the skills and experience required.

Software teams use story points to achieve more accurate and consistent estimation of how much work can be completed in a sprint. But more than that, the process of estimating story points forces teams to clarify the scope of work and align their understanding of when a task is complete.

To assign story points, teams will sit down and discuss the size of an issue together, assigning story point estimates. Sometimes they’ll use a digital card deck in a process called planning poker

You can consider some of the following factors when estimating work with story points:

Trying to compress so many factors into one estimate might sound impossible. But with some practice, it’s as simple as checking if the price of a flat white at your local coffee shop is fair.

💡 Top tip: Some agile coaches, practitioners, and gurus prescribe the factors that should go into your estimates. We suggest you choose those most relevant to your team’s circumstances and agree on them as a group. When in doubt, you can use effort, complexity, and risk.

When buying a coffee, you accomplish that feat in a split second by subconsciously comparing the price to various factors. Some are obvious, like the price, expected quality, and your experience at other coffee shops. But indirect factors also play a role, such as whether your current salary or the economic outlook justifies spending money on a fancy coffee.

The process for estimating story points is similar.

Say your team cleans cars, and three vehicles roll into your shop. Car A is rather clean already and small, so you all agree it’s one story point. Cars B and C are larger than Car A, making them double the number of points (2 points).

B and C also happen to be filthy, so that doubles the effort and hence their number of points once more (4 points).

For Car C, you also have to clean the interior, and you’re not allowed to look inside before you start the job. To factor in that risk, you add two more points for car C. 

The final tally looks like:

You know based on previous experience that you can complete roughly 30 points of work in a week. So you tell the owners they should be able to collect their cars in a couple of days. 

If you’d ask your team to estimate the car cleaning job in hours, they might give different answers depending on each person’s experience with cleaning cars. Or, they might spend a lot of time agreeing on how long it takes an average team member to do each vehicle before giving you an estimate.

By comparing the cars to each other and using an arbitrary number to express the differences in expected work, you get a much faster and less subjective estimate to work with.

You might still be thinking, “why would I use story points when I can just estimate how long it will take?” Well, using points instead of time can lead to faster and more valuable estimates. They can also spark helpful discussions about tasks and highlight issues that need attention during retrospectives.

Here are a few reasons why you might choose to estimate with story points:

Story points can help prevent teams from burning out at work. By measuring sprint velocity – the average number of completed points during previous sprints – and using that number as a limit for the next sprint, teams set a healthy and sustainable working rhythm. Story points force teams to decide which items to prioritize, which to split to fit their current sprint capacity, and what work to leave in the backlog for a future sprint.

💡Top tip: Teams calculate their velocity by counting the number of story points completed during a Sprint. This number, when averaged over a few Sprints worth of data, helps teams understand how many points of work they can finish in one Sprint. Velocity also serves as a conversation starter during retrospective meetings when the number turns out much higher or lower than usual.

📚 Learn more about measuring and using velocity here.

As with any well-intended tool, sprint velocity can be abused. This has given it a mixed reputation in agile communities. Instead of using velocity as the maximum a team could achieve, some organizations treat it as a commitment that teams must hit or even surpass every sprint.

Here’s what a conversation about team capacity-planning and story points might look like in reality:

Steven Langbroek, CTO at Recarb, doesn’t use story points for planning. Instead, he uses them to start discussions that uncover complexity, uncertainty, or risk. In fact, people commonly mention that they are simply a means of having better conversations and getting aligned.

By looking at something together and deciding what it is, you get shared understanding or identify where it’s lacking. Here’s what a typical conversation about story points might sound like in practice: 

When estimating story points, the actual numbers are unimportant, what matters is how they relate to each other. As Agile guru Mike Cohn writes:

It’s important to remember that estimating has a lot of unknowns. If you are estimating something, you need to dig into it, question things, and discover potential issues and problems.

When the team’s estimates vary a lot, have a conversation about them. Divergent estimates are evidence that your user story needs more discussion and refinement, so everyone aligns on the work involved.

Story points can act as signals for topics to discuss during retrospectives. Here are some ways to use them for this purpose:

Estimating complex work using time might feel more natural, but it has some disadvantages. Time is one-dimensional and absolute; it can’t reflect all the factors that story points take into account. Cognitive biases also cause us to overestimate how quickly we can complete tasks when we use time.

Story points don’t suffer from these disadvantages because they:

You can use story points to make estimates in meetings like Backlog Refinement, Planning Poker, or Sprint Planning. Here’s a step-by-step guide for using them with your team.

It took us over 1,500 words to arrive at a shared understanding of story points – or so we hope. Before overwhelming your team with numbers and terms like “Fibonacci scale” ensure they grasp the concept of story points in the first place! Sharing this article before your first estimation session might be a good start. 😇

One big challenge with story points is getting started without prior data to rely on. A common approach is to pick the smallest item you’ll ever need to estimate and give it one point. This story becomes your baseline task to which you calibrate subsequent ones. DevOps advocate Jonathan Hall calls this the “golden item.”

Choose another item from your backlog and estimate its size in story points relative to your baseline task. Continue running through your backlog this way, comparing stories to each other until you’ve assessed your most valuable items in various sizes. You can do this with an estimation method such as affinity estimation, relative mass evaluation, or our free Sprint Poker tool.

If a story is large and difficult to size up, break it into smaller items. Doing so makes estimating easier, and such large stories don’t fit into a sprint anyway.

Also, remember that estimation is not an absolute science. You’re not making a detailed plan for your next sprint. You’re just trying to roughly understand each item’s size to spark discussion and ensure you don’t take on too much work for your next sprint.

💡 Wondering how to estimate tasks as a team? Read our article on agile estimation techniques, including the Fibonacci Sequence, Planning Poker, Three-Point Method, and T-Shirt Sizing.

Create a story points matrix overview of various sizes you’ll commonly use. Add one or more reference tasks to help your team. Essentially, you’re creating a gold standard your team can look at when estimating work in the future. This is especially helpful for teams that have similar and recurring tasks, for example in a Kanban model.

You can also create a table that shows how the two main factors your team considers to size tasks affect the final number. In the example below, these factors are complexity and effort, but you can replace them with others.

You’re now ready to start your sprint. When it ends, calculate the total story points your team completed. This number is your team’s velocity.

After completing several sprints, measure your team’s average velocity. That number tells you – in story points – how much work you can realistically plan for each sprint.

Learn how to measure your sprint velocity by clicking here!

You’ll have more data and experience at the end of every sprint, so we recommend the following:

During the first few sprints, it’s likely that your velocity fluctuates. Over time, your team’s average velocity may gradually go up or down, depending on the goals you set. Don’t expect your team’s velocity to increase sprint over sprint in perpetuity; this is unrealistic and a recipe for burnout.

For example, you might find ways to improve your working processes, allowing you to complete more story points in a sprint and increase your velocity. But you could also choose to take on less work per Sprint to boost the quality of your deliverables. That would reduce velocity, but the outcomes would be positive.

Story points are tricky business at first, like arriving in a foreign country with a currency you’re unfamiliar with and trying to do the exchange rate in your head. Follow these pointers to avoid typical pitfalls and benefit from established story point practices.

📚 For tips on how to reach better story point estimates, click here!

There’s no need to estimate the entire backlog immediately. You only need to know the size of the items that might enter the first sprint.

Sizing too many items is a waste because you might need to estimate them again later as you learn more about your product, customers, and capabilities. Worse, many stories you estimate might never make it into sprint planning anyway.

As your team gets more familiar with story points, you can gradually work through more of the backlog.

To avoid conflating story points with hours or days, new teams can use a non-numerical proxy, like different-sized animals or fruits, as in the image below.

Even experienced teams can benefit from this practice, as breaking time-based estimation habits is hard. With numbers, it’s easy to start treating points as a proxy for hours or days again—not so with cute dogs. 🐶

The Fibonacci sequence is a series of numbers that grow exponentially because each number is the sum of the previous two numbers: 0, 1, 2, 3, 5, 8, 13, 21, and so on.

The reason for using Fibonacci numbers when estimating is to avoid wasting time on minor differences when sizing larger tasks.

Suppose your team needs to estimate a large task, like adding a new feature to your app. When you estimate this item with the team, one person suggests 31, another 36, and a third 38. While these numbers are similar, their minor differences can cause discussions, even long ones. Such a level of detail and discussion is unnecessary for most agile estimation situations.

The Fibonacci sequence makes it impossible to choose numbers close to each other for larger items. In the earlier example, most people would pick 34 because the other options are 21 or 55 (see the image below).

Story points are a local currency for estimation within your team, influenced by your unique skills, experience, and work process. You can’t make your points universal across multiple groups because then they become unwieldy, unusable, or misleading.

For example, your team might agree that creating a particular website form is two points, while another group views it as one point. This difference is okay as long as those estimates stay within each team.

Trouble begins when a manager gets involved and starts questioning why your team completed two points and the other only one.

When managers try to calibrate the points between teams, they make no sense. This can cause pressure for teams to start inflating numbers to please higher-ups, or wasting time synchronizing story point estimates.

Veteran agile consultant Tim Ottinger has a beautiful solution for such situations:

Story points take several sprints to get right, so don’t give up on them after just one try.

Once you have completed a few sprints, ask the team if they want to keep using story points. Their answer might surprise you.

It’s tempting to peg story points to time – “one story point = one day” – but that defies their purpose. You then turn them into a fixed unit of time, not a relative size that can account for various factors.

Story points should be fuzzy. A task rated two is likely larger than an item that’s a one and smaller than a three-point story. But we’ll never know if the task’s exact size is 1.6 or 2.7, and that’s fine. Story points aren’t meant to be precise – they’re estimates. That fuzziness doesn’t translate well to the preciseness of time and can create problems. 

When you convert story points to time, you either spend too much time ensuring estimates are precise or justifying why they’re so often wildly inaccurate.

What to do if you must have time-based estimates? There are two scenarios in which time-based estimates might be necessary:

Planning Poker is a popular estimation technique used by teams to estimate the size of user stories with story points.

Each team member gets a deck of cards with numbers. The team discusses a user story, and then each member selects a card representing their estimate of a story’s size. If there are wide variations, the group discusses the discrepancies and repeats the process to get to a shared understanding of the effort required to complete the work.

Parabol’s Sprint Poker meeting format lets teams estimate stories together remotely, turning a tedious task into a fun experience. Sprint Poker also makes the job of facilitators easier by pulling in stories directly from Jira, GitHub, or GitLab and syncing estimates back again. And it’s simply a lot more fun than trying to manage it any other way on a hybrid or remote team.

Getting teams to use story points is a challenging task, but the estimated size of the challenge shouldn’t stop you from trying when the situation calls for it.

Story points can work better than time estimates when you want to:

Don’t default to time just because we have used it for decades, and everyone instantly understands it. When your work requires a different way of estimating and measuring, consider using story points. They’re up for the task.

Story points create a lot of confusion, so there are many frequently asked questions about the concept. We’ve answered some of the most common questions that crop up time and again:

Story points are numbers software development teams use to express the size of a piece of work compared to other pieces of work. The values a team uses are unique because each group may consider different factors when assigning story points, like complexity, risk, and uncertainty.

Teams can use hours or story points to estimate how long their work will take. While hours represent a precise and universal unit of time, story points provide a relative and team-specific measurement.

One of the main issues with using hours to estimate is that they make it difficult to account for complexity and unknown roadblocks. Humans tend to underestimate how long a task will take, due to a cognitive bias known as the planning fallacy. This bias can cause teams to miss deadlines and over-promise.

Story points provide a faster and more flexible way of estimating work. Rather than trying to be precise, they provide a quick and reasonable estimate relative to other tasks. Points also factor in complexity, risk, and unknowns, which is difficult to do with time-based estimation.

A sprint doesn’t have a fixed number of story points. The number of points a team completes per sprint depends on various factors, such as how they estimate their user stories, the team’s size, and the experience and skill level of team members.

A team can get a rough estimate of how many story points fit into a sprint by calculating their sprint velocity.

The concept of story points was first invented by Ron Jeffries as part of the Extreme Programming (XP) agile framework. In this video, he explains that they used the points system to obscure the time element of estimates from managers.

Instead of communicating the number of “ideal days” a task would take – their original unit of measurement – they multiplied their ideal day estimates by three. They called the outcome story points and gave those numbers to their managers instead.

Jeffries has since apologized for inventing story points due to the confusion and abuse they have caused.

Story points aren’t officially part of Scrum since the Scrum Guide doesn’t mention them. The Scrum Guide has never mentioned story points since its first edition in 2010. But many Scrum teams use them nonetheless.

While they may not feature in the Scrum guide, Scrum’s co-creator, Jeff Sutherland, hints at them in his book, Scrum – The Art of Doing Twice the Work in Half the Time, when he talks about velocity:

People use “agile estimation points” and “story points” interchangeably. They mean the same thing.

Special thanks to Rebecca Sassine, Maarten Dalmijn, Stefan Wolpers, and the many others that contributed thoughts and provided insight for this guide.