Estimate Your Time Effectively with Agile Story Points

There is one major issue project teams struggle with time and time again: creating accurate estimations for sprint planning. A key component of Agile is accuracy, meaning working with subjective time estimations can become challenging. It is impossible to be accurate every time when you can’t account for changing scope, unexpected delays, or the other myriad of issues that come with project management.

While estimations aren’t always correct, it’s important to set the right expectations when planning a project. Accurate estimates help project managers and scrum masters plan sprints accurately, including task prioritization and resource allocation.

So, if time estimations fall short of the mark, what alternatives do we have? Read on to find out more about story points and how they can help estimate your time in Agile effectively.

• What are Story Points in Agile?
• What are the Benefits of Using Story Points?
• How to Calculate Story Points?
• How Forecast Can Help with Effective Sprint Planning

What are Story Points in Agile?

Story points are a technique that can be used in Agile project management to create a relative estimate of the effort and work required to complete a task or project. Many Agile teams opt to plan using story points rather than time estimates because it is based on the team’s analysis of how complex and risky a task is, rather than finger-in-the-air guesswork. 

While all project managers know that they need to create estimations, that doesn’t mean they know how to create estimates. Story points help clear up any confusion.

But, we’re getting ahead of ourselves. To understand how to calculate story points, we first need to understand what ‘user story’, ‘product backlog,’ and ‘product backlog item’ mean in the Agile development processes.

• User story: This term refers to a feature your end-user desires (e.g., ‘I want the website to play music upon loading’), which fits into the…
• Product backlog: This term refers to the list of user stories that need to be created and launched as part of the final product, which is completed based on…
• Product backlog item: While similar to a user story, a PBI refers to a single element of work in the product backlog. These come together to form the user story.

A story point estimates how much time and effort is needed to complete the work associated with an individual user story. A higher number equals more time and effort. What’s important to remember is that story points are relative, meaning they should be assigned on a comparative basis. This also means their values can be determined by your team; 12 story points could mean something entirely different to another team.

What are the Benefits of  Using Story Points?

You may be wondering why so many software development and project management teams are beginning to work with story points. After all, time estimates have been good enough for years. Why fix what isn’t broken?

The idea of story points may feel complex, but we recommend you stick with it. There are several benefits to working with story points over traditional time estimations.

You Get a More Accurate Calculation

Project managers know that projects rarely go to plan, regardless of whether you work within waterfall or Agile methodology.

Even time estimations that attempt to consider delays can’t account for all eventualities. No one can foresee how long a task will actually take, which is problematic as inaccurate time planning can have a huge impact on project progress.

Story points avoid making definitive commitments. Instead of stating that a task will take 3 days, story points provide a relative estimation of the effort required to complete a task.

That means fewer unmet deadlines due to inaccurate estimations and more flexibility to get the work done.

You Gain a Better Understanding of Sprint Velocity

If you’re questioning how story points are used for planning, here’s your answer. Sprint velocity outlines the amount of work your team can complete in each sprint. It is determined by your team’s efficiency as well as how fast they work.

By understanding your Agile team’s sprint velocity, you can make better estimations and decisions for the future. This is where story points roughly translate to time. Here’s how to calculate sprint velocity:

Let’s say your team needs to complete 90 story points, and it takes them 3 sprints to do so. Simply divide the story points by the sprint to calculate the sprint velocity: 90/3 = 30.

Story Points are a Non-Subjective and Relative Time Estimate

The reason why story points work so well is that they’re not subjective. Two project managers will never create the same time estimate because each will consider different factors and make different assumptions about how long each stage will take. Plus, time estimations can fail to consider team members’ experience levels; a more senior team member may only take a few hours to complete a task, but a more junior member could take twice that time.

The calculation of story points requires the Agile team to work together, collaboratively assigning points to each user story.

How to Calculate Story Points

Now we’re clear on why story points are a great technique to use, let’s talk about how to implement them.

Before You Get Started

• Get Clear on Your Scope

The number of story points allocated to each user story is dependent on the scope of work.

For example, updating all the images on one webpage won’t take nearly as much time and effort as sourcing, getting approval, and uploading images for an entire 20-page website. That means the second task will have more story points, though not necessarily 20 times that of the first task, depending on the complexity of each web page.

Some user stories can also lead to additional work if a change affects another area of functionality.

• Calculate the Project Risk

The risk or uncertainty associated with a user story will affect the value of story points allocated. If the scope is unclear (for example, the stakeholder asking for a user story to be actioned hasn’t created an effective brief, or your team is implementing a tool they haven’t used before), that uncertainty and risk should be reflected in the estimate.

• Be Realistic About the Project’s Complexity

Two tasks that look similar on the surface can have completely different levels of complexity.

For example, developing one web page could be as simple as creating a landing page that features one image, body copy, and a newsletter sign-up element. It could also be as complex as developing a page that hosts 2,000 products and auto-loads when scrolling, and features a sign-up element at the bottom. Counterintuitively, two tasks that seem wildly disparate on the surface in terms of effort required could require the same number of story points.

• Create Your Reference Story

You’re now ready to get started with calculations. Typically, project managers use a method devised by engineer James Grenning called Planning Poker, an estimation and planning technique for Agile.

First, you need to set your reference story. You can choose any completed user story from a previous cycle. For simplicity, you may want to select a story that was assigned a story point of 1. If you haven’t used story points before, select your most simple, previously completed user story. At this point, you should have your new product backlog of user stories laid out.

• Select Your Scale

Agile teams have two scales of estimation to choose between; the linear scale and the Fibonacci scale. The latter uses numbers from the Fibonacci sequence, in which each number is the sum of the preceding two numbers. These include 0, 1, 2, 3, 5, 8, 13, 21 and so on. This scale is used to estimate growth in many disciplines and provides a realistic way of approaching estimations.

Draw a table with the story points based on the Fibonacci scale ascending on the left. The user stories will be filled in on the right.

• Begin Planning

This is when you begin to fill in the table. Consensus is critical in planning poker, so this step should take part in an Agile estimation meeting that everyone who will inform the planning attends.

During the meeting, each user story on the backlog is discussed at a time. After discussing the product backlog items in detail, each person involved in the estimation reveals what number they would assign to the user story. Once the table has been filled in with all the user stories, the task is completed. Remember, more than one user story can be allocated the same amount of story points.

• Calculate Velocity and Nail Down Your Schedule

Once the sprint backlog has been created, the first sprint can begin!

Following the first sprint, a sprint retrospective meeting is held, during which the team’s velocity is calculated based on the number of story points completed.

For example, if you completed 30 story points in your first sprint out of 300 story points total, you can estimate that it’ll take 10 sprints to complete the project.

This step can be repeated after each sprint to refine the calculation and will help when planning future projects. Remember the formula from earlier? The number of story points divided by the number of sprints = sprint velocity.

How Forecast Can Help with Effective Sprint Planning

Sprint planning needn’t be hard work. Forecast’s dedicated sprint planning settings can help you plan more effectively for the future while you focus on nailing your user stories.

Our story points system makes it easy for you to see sprint velocity and track the performance of your sprints. The platform automatically relates your team's time registrations to story points based on configurable options. When your sprint velocity changes against the expected performance that you set, Forecast automatically lets you know.

It's a clever little feature that makes it simpler than ever to stay on top of your sprints. And, as you get to know the platform, you'll find that it's not the only smart feature built specifically to make life as a scrum master or PM easier!