How to use Story Points in Agile (step-by-step guide)
Despite what we think, we’re actually terrible at estimating projects. Studies show that 91.5% of big projects go over budget, over schedule, or both. There needs to be a better way to estimate the work ahead of us.
Story Points are a powerful way to estimate Agile projects, focusing on the total effort to complete a task, rather than just the time it will take.
This provides a more rounded view of the complexity, expertise, and resources required, while also giving development teams flexibility by not committing them to hard dates.
Jump to a section:
If you’re a project manager, developer, or team leader that’s struggling to estimate your sprints accurately, then this article is for you.
We’ll break down what Story Points are, why they’re better than traditional time estimates, and how you can use Story Points inside Planio to level-up your next sprint planning cycle.
What are Story Points? How are they used?
Story Points are a relative unit of measure, defined by individual development teams, to estimate the effort, complexity, and scale of completing a particular task.
Typically, Agile teams align their Story Points scale to a simplified Fibonacci sequence. Here, each level of estimate is the sum of the two before it (e.g., 5 = 2 + 3), providing clear differentiation between each one.
Here’s an example of the simplified scale:
1, 2, 3, 5, 8, 13, 20, 40, and 100.
So, if a development team estimated eight Story Points to build a bus, you’d know that it was around the middle of the road in terms of complexity, scale, and overall effort.
There are several factors teams consider when determining a score for each piece of work, including:
- Complexity. The level of technical difficulty of each task.
- Repetition. Whether the task, or one similar, has been done before, and therefore, whether the team has existing knowledge.
- Resource. Whether the task requires effort from multiple team members or can be completed by one person alone. This should also consider if any external resources are required.
- Risk. How risky the changes are to the existing solution, the business operations, or the success of the project.
- Definition of Done. Underpinning all of this is the project’s definition of done, which details the quality standards every item must meet. The higher the standard, the more effort is required.
Estimating Story Points is a core part of the backlog refinement process, where development teams get together with the Product Owner and/or Project Manager to estimate business requirements, and turn them into User Stories.
This is a collaborative process, where each team member shares what they believe the estimate should be, and then the team works to reach a consensus.
It’s super important that everyone agrees on the final Story Point estimate, as they’re used to determine how many User Stories the team will commit to in their next development sprint.
As development teams complete more and more work, they typically become more accurate with future Story Point estimates. This improves team efficiency and ensures they know their weekly, fortnightly, or monthly capacity — known as Team Velocity in the Agile world.
Why use Story Points instead of time when estimating tasks?
It can take time for some people to get their head around Story Points. This is because the concept is difficult to explain without a level of context or a common reference point to connect it to.
This famous article brings Story Points to life, by using the example of being asked to estimate the size of a dog.
If someone asked you how big a German Shepherd was, you’re unlikely to say “about 25 inches high”. Instead, you’re more likely to compare it to another dog breed that you both know, for example, “a German Shepherd is a little bigger than a Labrador.”
This optimizes why Story Points provide a richer estimate than time alone.
Once development teams have common reference points for each of their Story Point estimates, it instantly makes it easier for them to predict the complexity, scale, and effort of future tasks.
To bring the comparison to life, let’s take a look at how time and Story Point estimates compare side-by-side:
Time | Story Points |
---|---|
Only focuses on the amount of time a task will take. | Considers the complexity, scale, and effort required to complete the task. |
Time-based schedules are one dimensional | Story Points use common reference points to create richer, context-driven understanding |
Don’t account for other time-based tasks (such as meetings and messages). | Account for uncertainty, risk, and complexity. |
They are easier to explain to stakeholders. | They are more challenging to explain to stakeholders without context. |
6 additional benefits of Story Point estimates
Alongside richer descriptions, Story Point estimates have a range of other benefits for development teams and stakeholders.
Let’s take a look at some of the more common benefits on offer:
- Helps to speed up planning sessions. Once the team has a shared understanding of Story Point values, it makes the whole planning process much faster. Rather than spending extra time completing detailed fact finding, items can be easily estimated against previous deliveries.
- Doesn’t tie team members to specific time commitments. When we’re forced to commit to cost or time estimates, other factors, such as unconscious bias and political pressure, often cause those estimates to be wrong. Instead, by not tying teams to time commitments, you often make estimates more accurate.
- Bakes uncertainty and risk into the estimation process. Because Story Points don’t just focus on time, they inherently factor in other areas such as complexity, risk, and uncertainty. This makes estimates more accurate, and helps teams plan their deliveries with these factors in mind.
- Accurate enough to plan the next sprint. By using fact-driven, comparative scales, Story Points are a great way to kill perfectionism while being accurate enough to proceed. This helps boost team velocity while still giving stakeholders confidence in the process.
- Hones your estimation skills over time. As teams complete more and more deliveries, their Story Point estimates become more accurate thanks to additional reference points.
- Boosts team collaboration. Story Point estimating is a collaborative process that makes planning more fun while providing a level playing field for everyone involved. This boosts team collaboration, helps enhance connections, and improves morale over time.
Story Points are a powerful way to gauge the total effort to complete a task, rather than just get fixated on the time it will take.
How to start using Agile Story Points with your team today
Now that you know what Story Points are and the benefits they bring, it’s time to start putting them into practice within your team.
Read on for a step-by-step guide on implementing Story Points, including extra resources to help you along the way.
1. Make sure your team understands the purpose and value of Story Points
Before you get started with any new way of working, it’s important to ensure your team is on board. Making the shift to Story Points is no different, especially given it’s a tricky concept for some to master. So, take your time to ensure everyone understands the value of Story Points.
- Try to inspire and motivate your team. With any change, you need to sell the benefits of Story Points to your team to get them to buy in. Read this article to master techniques that will help you inspire your team.
- Use different communication methods. Not every team member is the same, so use different communication methods to convey the idea to your team. This includes out-of-the-box techniques such as asynchronous communication and one-to-one meetings.
2. Decide on a Story Point scale to use
Most Agile teams use a variation of the Fibonacci sequence as their Story Point scale. When getting started, it’s best practice to simplify it slightly, using rounded numbers to make estimates easier to understand and work with (e.g., 1, 2, 3, 5, 8, 13, 20, 40, and 100.)
- Transition using t-shirt sizes. If your team is struggling to grasp the Story Points concept, another popular estimating technique used by Agile teams is t-shirt sizing. It’s similar to Story Points, but instead of numbers, you use Small, Medium, Large, Extra Large etc. to estimate pieces of work.
- Create reference points. When deciding on your Story Point scale, use two or three previous projects as reference points to help the scale make sense. A small bug fix might score a 1 on your Story Point scales, whereas a large website redesign might sit at the 100-point mark. These references provide context for newer team members.
3. Document your scale using a Story Point matrix
With your scale and reference points identified, it’s time to really put some structure around your estimates by creating a Story Point matrix. This matrix will serve as a handy crib sheet for your team, helping them combine the varying levels of effort, resource, risk, and complexity to come up with a considered estimate.
Try using our template below to help you get started building your own Story Point matrix:
Make sure your entire team is aligned on the matrix to ensure everyone is using the same baseline when forming your estimate consensus during sprint planning.
4. Groom and update your product backlog alongside the Product Owner
Now that your Story Point scale is ready to use, it’s time to start preparing your product backlog. Led by the Product Owner, teams work to prioritize requirements, remove irrelevant tasks, add any new items, and ensure all requirements are well-defined and ready for sprint planning.
- Know your strategy. Product backlogs must be aligned to the aims of the product, whether that’s helping users solve problems or exploit new opportunities in their businesses. As you dive into backlog grooming, make sure your team is aligned on the product strategy to help them make the best decisions on what to start and stop.
- Brush up on your Scrum and Agile knowledge. Backlog grooming is the foundation for many Agile project management frameworks, including Scrum. If you’re a little rusty, use our guides above to help you refresh your knowledge.
- Use a prioritization framework. Knowing which features to kill is a skill that takes time to master. If you’re new to backlog grooming, use a feature prioritization framework, such as RICE, to help guide the team on the right items to put at the top of the list to best meet your objectives.
5. Make estimating features and projects more fun
With your backlog up to date, it’s time to add the final piece of the puzzle: the estimates. This is when you truly begin to put Story Points into action, as each team member comes up with an estimate for discussion and alignment. There are several ways to make estimating more fun, let’s look at two of the most popular.
- Planning Poker. The most common way of estimating with Story Points is to play planning poker. Each team member has a pack of Story Point cards, and takes turns to ask the Product Owner questions about a feature. Once all questions have been answered, each team member selects a card and turns it over at the same time. Teams discuss their estimates and repeat the process until everyone reaches a consensus.
- Bucket System. In the bucket system, the facilitator places post-it notes horizontally with the highest and lowest Story Point values at each end. Each team member has cards representing each feature and places them where they believe they should be on the Story Point scales. Teams discuss their differences until they reach a consensus on the right estimate.
6. Plan your sprint in your project management tool
Now that your backlog is groomed and everything is estimated, it’s time to start planning your next sprint. Here, teams select the features they want to work on, agreeing among themselves how many they think they can deliver within the sprint window. Once agreed, the sprint is started and development begins.
Here’s how you can use Story Points to plan your next team sprint in Planio:
Planio’s Agile project management features include dedicated sprint planning modules that bring your entire team together in one place, boosting transparency, alignment, and team morale.
Once your product backlog is in Planio, you can start to groom tasks, estimate Story Points, and pull tasks into your next sprint, using your preferred project management style, including Agile, Scrum, and Kanban.
To change your default estimation units to Story Points, you’ll need to change your settings under Administration → Agile Board → Story Points.
Next, you’ll be able to include Story Point estimations, which will be visible on your Agile board — including total Story Points of all tasks in each column.
You’ll also be able to quickly create Story Point burn-up and burn-down charts to track your progress.
In Planio you can follow our guide to set up your Agile board and Story Points and learn more.
7. Use sprint retrospectives to improve your Story Points estimation
After every sprint, all good Agile teams get together to assess what went well and what could be improved. When it comes to project estimating, you’ll find that your estimates get more accurate over time as you build up more reference points for the future.
- Run a good retrospective. Check out the Planio guide on how to run a good retrospective to ensure you get the most out of the session. As well as assessing Story Point estimates, retros are a great chance to improve ways of working, team morale, and collaboration for the future.
- Track metrics to monitor performance. Data is king in so many parts of business, and Agile teams are no different. As you and your team grow over time, start tracking Agile metrics such as velocity, cumulative flow, lead time, and issue burn up to help you become more efficient and deliver greater value.
5 common mistakes teams make using Story Points in Agile
While Story Points can be a complex concept to master, they’re made a lot easier if you can avoid some common pitfalls.
We’ve pooled our development experience to highlight the top five mistakes we’d recommend you stay clear of:
- Don’t equate Story Points for hours or days. It’s easy to fall into old habits and quickly convert Story Points into hours or days when communicating to stakeholders. Avoid this at all costs to ensure you’re focusing on effort and complexity without tying yourself to hard headlines.
- Make sure your Story Point scale is relative. No two products are the same, so make sure your Story Point scale aligns with your product and is relative to the size, scale, and type of work you do.
- Embrace the uncertainty of Story Point estimation. Story Point estimates are intentionally broad to help teams focus on doing good work, rather than clock watching. This can feel a little uneasy at first, but try to embrace the uncertainty of Story Point estimates and use that flexibility when managing stakeholder expectations.
- Invest time in explaining the scale to stakeholders. Let’s face it, business stakeholders have spent years using time estimates to plan their work, so it takes some time to adjust to Story Points. To help, invest time in educating them on the concept and how it will make development teams more effective over time.
- Stay consistent with Story Point estimation. When teams face a bump in the road, it can be easy to blame Story Points for their failure, ditch the concept, and move back to traditional time estimates. Instead, we’d encourage you to stay consistent with Story Points. Once teams are in the swing of the process, they usually become a far more effective software development unit.
Want to go a step further? Try the #NoEstimates approach
If you’re struggling to accurately estimate your projects, Story Points are a powerful way to gauge the total effort to complete a task, rather than just get fixated on the time it will take. This provides a more rounded view of the complexity, expertise, and resources required, while also giving development teams flexibility by not committing them to hard dates.
While Story Points are good, they’re not the only alternative approach available. The #NoEstimates movement encourages development teams to not focus on providing estimates and instead place all their focus on breaking down and delivering smaller pieces of value.
It’s a controversial approach, but one that has some strong advocates across the software development community.
Ultimately, whether you use time-based, Story Points, or #NoEstimates, project teams must deliver work that contributes to the company’s goals. Managing that work is always easier when using a project management tool like Planio to create alignment, boost collaboration, and promote accountability. Combine those three characteristics, and you’ll deliver great features that your stakeholders love every single time.
Try Planio with your team — free for 30 days (no credit card required!)