Skip to main content

How to Create Better Story Point Estimates

parabol-better-story-point-estimates (1)

Story point estimation helps agile and Scrum teams plan their work, measure their progress, and make informed decisions about how to allocate resources. However, creating “accurate” story point estimates is easier said than done. It might even be a contradiction in itself. 

The fact is, humans are not very good at estimating how much effort something involves, or how long it will take. We routinely under-estimate the effort or time required to complete a task. There’s even a name for this cognitive bias: the planning fallacy!

In this article, we’ll explore some tips and strategies for creating better story point estimates that will help your team to work more effectively, deliver higher-quality software, and manage stakeholder demands better.

🤔 Wait… what are Story Points again? Refresh yourself with our accessible overview

1. Use a consistent scale

One of the most important factors in creating better story point estimates is using a consistent scale from sprint to sprint.

This means that everyone on the team should have a clear understanding of what each point on the scale represents and that scale should not change.

It’s hard to reach a reasonable estimate when your team is not aligned on the value of a story point.

A common scale used by agile teams is the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.). Each number in the sequence represents a relative level of effort, with higher numbers indicating more complex or time-consuming tasks.

explanation of fibonacci sequence benefits: precision and breadth

Using a consistent scale helps to ensure that team members are on the same page when it comes to estimating the effort required for each task and the amount of work that can fit into one iteration. This, in turn, helps to make the estimates more accurate and reduces the likelihood of misunderstandings or miscommunications.

You can get aligned on the value of a story point by setting a baseline. Take some user stories you did in the past and give it a rating on the scale. Then compare everything you estimate to that baseline. Is it bigger, or smaller? This is also known as relative estimation.

Fibonacci isn’t the only scale you can use. Parabol’s Sprint Poker estimation tool has a bunch of scales built right in so you can estimate story points easily. If estimating based on abstract numbers seems too complicated, try starting with the T-Shirt Sizing scale. It’s more intuitive since estimates range from small to extra large – just like clothing!

2. Break down tasks into smaller units

Make sure you’ve broken down tasks into smaller units before estimating. As a rule, if a task is obviously too big to fit into one sprint, you should always break it down into smaller components. 

Once you’ve done that, each of your component tasks can be estimated separately. This approach can help to make estimates more accurate by reducing the amount of uncertainty associated with larger, more complex tasks. The bigger the task, the more unknowns there are. 

For example, instead of estimating the effort required to “implement a new integration,” the team could break this task down into smaller subtasks such as “write the code for the integration,” “test the integration,” and “submit the integration to the marketplace.” 

Each of these subtasks can then be estimated separately, based on the relative level of effort required.

3. Consider previous experience

Story point estimation should get easier the more you do it. That’s because your team will have built up shared context and experience around the relative size of tasks. So always ask the team to consider their previous experience with similar tasks. 

For example, if your team has implemented a similar feature in the past and it took them one sprint to complete, they may be able to use this information to estimate the effort required for a similar feature in the future. 

However, it’s important to keep in mind that every task is unique, and previous experience should be used as a guideline rather than a strict rule.

“Story points represent a range of time, complexity and uncertainty or risk.  The goal is shared understanding. The easiest way to get shared understanding of anything is look at something together and decide what it is. Then look at something else and decide how it’s the same and how it is different. Now you are building shared understanding.”

Scott Weiner , Transformation Practice Lead at NeuEon Inc

4. Involve the whole team

Diverse opinions and skillsets help developers consider estimates from all angles. So the whole team should be involved in the estimation process. Everyone should have the opportunity to provide input on the estimates, based on their own knowledge and experience.

By involving the whole team, you can benefit from a wider range of perspectives, expertise, and skill levels which can help to make the estimates more accurate. This has the bonus effect of helping to build a sense of ownership and collaboration, which is beneficial for team morale and productivity.

One of the worst things you could do is have your product owner or product manager independently assign story point values without the input of the team. It may sound crazy, but we’ve seen it happen before! 

5. Refine estimates over time

Story point estimates are not set in stone. As your team progresses through their sprint, they may gain new insights or encounter unforeseen challenges that will make estimates inaccurate. 

Some teams find it helpful to refine estimates over time as new information becomes available. This not only gives a sense of whether the task can still be completed within the sprint, but it provides useful information when you come to compare similar tasks in the future.

It usually makes more sense to amend story point values after the task has been completed, so you can compare estimated vs actual after the fact rather than during your sprint. 

Don’t feel down if a task ends up being more complex than you thought. It will happen from time to time. Just roll it over into your next sprint and amend its estimate on the sprint backlog.

Refining estimates contributes to the continuous learning process new and established teams go through when working together. 

The biggest fallacy in story points is not updating them as you learn more information. I want velocity to be the sum of the story points we did, not what we thought we would do! When you make this tweak that Story Points are updatable, they become immensely useful!

James Rooney, Agile Coach and Founder at Agile Toolkit

If you’re having problems with estimation, sprint planning, or agile story points, you can always run a Parabol retrospective to discuss what’s working and what’s not. From there you can come up with some action items or experiments to try next time. 

Note that this approach is not entirely by the book. Many coaches will tell you it’s a bad idea to amend your estimates after (and especially) during the sprint, because it’s a waste of time or confuses the self-contained sprint process. However, we do think it can be helpful for increasing the accuracy of your estimates over time and exposing under/over-estimation.

6. Let technology help you

It’s not all on you to stage manage an agile estimation session. There are some great tools to help you with it.

Parabol’s planning poker tool helps team members participate in estimation sessions remotely, using a simple and intuitive interface and colorful card deck that makes it easy to vote on estimates and discuss tasks in real time.

It also includes features like timeboxing, which helps to keep the estimation process on track and prevent it from running over time. Parabol’s Sprint Poker tool can help teams to create more accurate and informed estimates, leading to better planning, more effective use of resources, and ultimately, higher-quality software.

It comes built in with a bunch of scales and estimation types to play with, and integrations with your backlog management tool (Jira, GitHub, GitLab, or Azure DevOps)! It’s free for up to two teams, so why not give it a spin for your next estimation session?

“Using Parabol, our teams are getting more consistent velocity in their sprints, their committed versus planned is more consistent, and their effort is more in line with what they’re setting out to do”

David Murphy, Engineering Lead at Ebury

Estimates are not an exact science

Creating accurate story point estimates is a valuable way for development teams to get on the same page whether or not you’re using it to align as a team, refine your product backlog, or calculate sprint velocity

But before you go, remember that story point estimates are not a perfect science, and there will always be some degree of uncertainty and variability involved. The goal of estimation is not to be 100% accurate, but rather to provide a useful guide for planning and decision-making. In fact, the idea of “accurate estimates” is oxymoronic.

An “accurate estimate” is like asking for a “steaming hot frozen beverage”.

Samir Karandikar, Professional Scrum Master and Program Manager at Atlassian

With practice, persistence, and continuous learning your team can develop the skills and expertise needed to create better story point estimates and deliver higher-quality software. Just be aware that creating better estimates is a process that may take some time!

📚Further reading

Gareth Davies

Gareth Davies

Gareth is the Content Lead at Parabol. He has spent his career helping people and organizations around the world communicate better. He likes learning languages, cycling, and journalling. He originally hails from Wales, but lives and works in Munich, Germany.

Try Parabol Sprint Poker For Better Story Point Estimates

Estimate remotely with an interactive deck of cards, built-in anonymity, and two-way integrations with Jira, GitHub, Gitlab, and AzureDevOps. Sprint Poker makes estimation meetings fun, gets people talking, and helps teams craft better estimates.