How to Create Better Story Point Estimates

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

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.

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!

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.

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.

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! 

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. 

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.

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?

📌 Read more about how EBury improved their sprint velocity using Parabol’s Sprint Poker.

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.

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