Skip to main content

What Are Story Points and How Do You Use Them?

gambling table image

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:

What are story points?

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:

  • 🏋️ Effort: All the work necessary to complete the task, including Quality Assurance (QA) as defined in your Definition of Done.
  • 🕸️ Complexity: The number of elements involved, their interdependence, and the need for research.
  • ⚠️ Risk: How much of the task is unknown or risky at the moment of estimating?
  • 💡 Experience: The team’s previous experience completing similar tasks.
  • 🤝 Collaboration: The amount of cooperation the task needs within the team or with other parties.

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.

Story points example

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:

  • Car A: 1 point
  • Car B: 4 points
  • Car C: 6 points
  • Total: 11 points

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.

Why do agile teams use story points?

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:

To make quick estimates for capacity planning

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.

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:

“We would meet with the business and say ‘we completed 23 points last week. Todd is going to take a vacation in the coming week, so we can only offer you 18 points this week.’ The business person would say ‘very well, if I only have 18 points, then I want these stories…’ and they would list out roughly 18 points of stories for us to do.”

Tim Ottinger, Agile consultant

To create shared understanding

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.

“The numbers don’t matter, it’s the conversation that follows when the Story Points are different that matters.”

Maarten Dalmijn, Product Management Leader at Dalmijn Consulting

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: 

“Oh that’s a 13, didn’t realize the complexity there, can we break this up into more manageable tasks so we can deliver it this sprint or assign it to more than one person? Similarly, you think that’s a 3, did you take into account the database changes you’ll need to make? Or that seems small to me, are you sure we both understand what sort of changes and testing this ticket will require?”

David Flynn, Developer

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

“Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers.”

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.

“Arguably the main benefit of agile estimation is that it helps teams get better aligned by forcing them to question their existing assumptions about a task. The person facilitating the meeting should do their best to open up that communication, and help teams understand the reason behind estimates. This allows teams to be aligned and start to see where potential problems could arise and how to mitigate them.”

Victor Purolnik, Product Advisor to startups & Founder of Trustshoring

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.

To inform topics for retrospectives

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

  • ⬇️ Velocity is much lower than expected. Are there more bugs from previous sprints? Is a tool or process slowing you down? Consider any potential issues that may be clogging up your progress.
  • ⬆️ Velocity is much higher than expected. Are improvements from your last retro more effective than expected? Has the team learned new skills, tools, or practices that have increased speed?
  • 🐘 An item was poorly estimated. When the team completely underestimates or overestimates a story, discussing it during the retrospective can help to improve future estimates.
  • 🐌 A team member completed very few points. While you shouldn’t use story points as an individual performance metric, a minuscule number can signal someone is struggling – professionally or personally – and needs support.

To account for unknowns

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:

  • ⚖️ Are relative. You arrive at their value by comparing tasks to other, already estimated items. Such relative estimation is much easier and faster than trying to arrive at precise values as you do with time.
  • 💣 Account for unpredictability. They consider risk, uncertainty, and a team’s previous experience. We often forget such factors when we estimate using time or only add them by spending many hours calculating various scenarios.
  • 🤗 Are collaborative. They’re a size estimate from the whole team based on their skills and abilities rather than how big or small a task is for an individual. When estimating in hours, one item might take two hours for the senior person but ten for the junior.
comparison of story points versus time estimation

How do you “calculate” story points?

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.

1. Explain the concept to the 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. 😇

meme showing a crazed man trying to explain story points to his team

2. Set a baseline task, then compare other items to it

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.

3. Create a reference table for future estimates

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.

example of how story points would apply to an epic like "making apple cider"

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.

4. Execute your sprint and measure its velocity

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.

example of a sprint velocity graph and how story points may vary in the first few sprints

5. Repeat steps 3 and 4 every sprint

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

  • 📋 Update your story point sizing table to reflect the latest information you have. As your experience using story points evolves, your table may need adjusting. The end of a Sprint is a great time to do so.
  • 🏁 Calculate your velocity and compare it to the previous Sprint. Is it roughly equal? Did you blaze through more story points? Talk about why velocity may have gone up or down during your retro, and use the insights to make adjustments and ensure you’re still planning the right amount of work for your next sprint.

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 best practices

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.

Don’t estimate the entire backlog on day one

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.

Use objects instead of numbers for new teams

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

alternative scales for agile estimation: dog sizes, fruit sizes

 

Combine story points with the Fibonacci sequence

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

explanation of fibonacci sequence benefits for setting story points: precision and breadth

Keep story points within your team

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:

“I tried to deal with this problem by having teams name their story points after favorite types of fruit. One team would measure velocity in oranges, another would measure it in apples, another in kiwis, etc. Then, when management invariably tried to compare the velocities of teams, I would tell them that ‘You can’t compare apples to oranges.’”

Give story points a few sprints to prove themselves

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.

“I recently asked my teams if they wanted to abandon points when in a planning session. They all unanimously agreed not to. Which surprised me, but they were still early in sprints and they said they valued pointing as they could understand if the ticket needed to be broken down if it was too large for the sprint.”

Mathew Wade, Agile Practice Lead, Espire Infolabs

Be careful converting story points to hours or days

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:

  1. Your team needs time data for other purposes. Say you want to calculate the average time your team spends on one user story. You can divide your velocity by the number of person-days or hours that went into a sprint to get the time that goes into each work item. This calculation can also help predict how long it will take to complete your backlog, but remember only to use such numbers within the team.
  2. Others in your organization demand you translate story points to hours. In that case, forget about points and start calling them hours. That makes everyone’s lives easier by avoiding needless confusion and calculation.

Play Planning Poker for better estimates

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.

Time estimation isn’t superior because it’s simpler

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:

  • Spark a discussion in your team to create a shared understanding of complex, risky, or unpredictable work items.
  • Plan capacity for your upcoming sprint roughly and quickly.
  • Measure velocity as a signal to use in retrospective meetings.
  • Use Sprint Poker and other agile estimation techniques.

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 FAQs

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:

What is a story point?

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.

Story points vs hours: what’s the difference?

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.

How many story points are there per sprint?

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.

Who invented story points?

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.

Are story points part of Scrum?

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:

“We have all these stories—these things that need to be done. And we’ve estimated them—this one is an eight, this one a three, and so on. And then we start on our first Sprint. Let’s say it’s a week long. At the end of the week we count up all the stories we’ve completed, total the points they were estimated at, and that number tells us how fast the team is going, their velocity. And once you have a velocity, you can look at how many stories you have left and how many points they represent, and then you know when you’ll be done.”

What are agile estimation points?

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.