Agile Story Points: Measure Effort Like a Pro

Story points can be a little confusing and are often misunderstood. Story points are an important part of user story mapping, and many agile teams use them when planning their work. But they aren't as simple as adding numbers to tasks or estimating how long a job will take.

Even if you’ve been using story points for a while, you’ll find that different teams and organizations will use them differently.  

So, let’s define story points, discuss why they’re so useful for agile teams, and talk about some of the different ways teams implement them in story mapping and sprint planning.

What are user story points?

Story points are a useful unit of measurement in agile, and an important part of the user story mapping process. You assign a number to each user story to estimate the total effort required to bring a feature or function to life.

When to estimate story points

User stories can be estimated during user story mapping, backlog refinement, or during sprint planning.

Once a user story has been defined, mapped to the backbone, and prioritized, it's time to estimate the story points. It is a good idea to work with your team to do this, as each team member plays a different role in different stories, and knows the work involved in UX, design, development, testing, and launching. Collaborating on story point estimation will also help you spot dependencies early.

It is best to assign story points to each user story before you sequence them into releases or sprints. This allows you to assess the complexity, effort, and uncertainty of each user story in comparison to others on their backlog, and to make informed decisions about the work you decide to commit to each sprint or release.

How to estimate user story points

When estimating story points, you're looking at the total effort involved in making that feature or functionality live so that it can deliver value to the customer. Your team will need to discuss questions like:

• How complex is the work?
• How much work is needed?
• What are the technical abilities of the team?
• What are the risks?
• What parts are we unsure about?
• What do we need in place before we can start or finish?
• What could go wrong?

Tip: If you're having trouble estimating a story or the scope of work is overwhelming, you might need to break your story down into smaller parts to make multiple user stories.

What is a story point worth?

This is where story points can get a little confusing, as story points don’t have a set universal value. You kind of have to figure out what they’re worth to you and your team (yep, real deep and meaningful stuff).

Here’s how it works:

• Each story is assigned a certain number of story points
• Points will mean different things to different teams or organizations
• 1 story point for your team might not equal the same amount of effort involved in 1 story point for another team
• The amount of effort involved in 1 story point should remain stable for your team each sprint and it should remain stable from one story to another
• 2 story points should equal double the effort compared to 1 story point
• 3 story points should equal triple the effort compared to 1 story point… and so on

The number you assign doesn't matter - what matters is the ratio. The story points should help you demonstrate relative effort between each story and each sprint.

Estimating story points for the first time

Because story points are relative, you need to give yourself some baseline estimates for the first time you do story point estimation. This will give you a frame of reference for all future stories.

Start by choosing stories of several different sizes:

• One very small story
• One medium sized story
• One big story

...a bit like t-shirt sizes.

Then assign points to each of these baseline stories. Your smallest story might be 1. If your medium story requires 3 times more effort, then it should be 3. If your big story requires 10 times the effort, it should be 10. These numbers will depend on the type of stories your team normally works on, so your baseline story numbers might look different to these.

The important thing is that you’ll be able to use these baseline stories to estimate all your future stories by comparing the relative amount of effort involved.

Over time, you and your team will find estimating user stories becomes easier as your shared understanding of the work develops. This is where story points become most valuable, helping your team align expectations and plan more effectively.

Make estimation easier

An app for Jira like Easy Agile TeamRhythm makes it easy to see team commitment for each sprint or version, with estimate totals on each swimlane.

Using the Fibonacci sequence for story point estimation

Some teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.) for their story point estimates, rather than staying linear or allowing teams to use any number (1, 2, 3, 4, 5, 6, 7, etc.).

This has its benefits. For example, if you're looking at a story and trying to estimate whether it's a 5, 8, or 13, it's much quicker and easier to come up with an answer than trying to land on the right number between, say, 4-15. You'll likely reach a consensus much more quickly.

This also means you won't be able to average the team's story points to finalize the estimation. Instead, you'll need to discuss the work and decide on the best estimate from a limited set of options.

But it does limit your options - if you have a story that’s more effort than 34, but less than 55, your estimate might be less accurate.

Using story points to estimate velocity

After some time working together most teams will have a good idea about how much effort is involved in each story point.

Of course, timing isn't exact - there's a bell curve, and story points are designed to be an estimate of effort, not time.

But story points (and knowing their approximate timing) can be useful when it comes to figuring out how much your team can get done each sprint.

You should be able to estimate about as many story points your team can manage during a two-week sprint, or whatever timeframe you’re working to.

For example, if your team can usually get through 3 story points per day, this might add up to 30 story points across a two-week sprint. This is your velocity.

Velocity is useful for user story mapping and sprint planning. When mapping your user stories to sprints or versions, you can check the total story points and make sure it matches up with your velocity so you’re not over- or under-committed.

As you can see there are a few different methods for estimating work. The best advice is to be conservative and not overload the team.

Over time, your estimations should become more accurate.

Using Story Points in Scrum, Kanban, and Extreme Programming

Story points are central to estimation and planning processes in many agile methodologies. Scrum and Extreme Programming (XP) rely heavily on story points to gauge the effort and complexity of user stories.

Scrum teams use story points during sprint planning to decide which tasks to include in the upcoming sprint, encouraging discussion that leads to shared context and understanding of the work.

Extreme Programming on the other hand, uses story points to assess the size of features, enabling teams to prioritize and allocate resources effectively. Teams using Kanban can benefit from story points by using them to set work-in-progress limits and optimize the flow of tasks across the board.

While the specific practices may differ, story points can help encourage team collaboration and a more predictable flow of work.

There are many good reasons why so many scrum and agile teams are adopting story points.

‍

1. Fast estimation

User story points allow you to quickly estimate the work involved in each item on your backlog, and how much work you can get done in a sprint or release.

2. Build consensus and collaboration

If one team member estimates 5 story points, but another estimates 12, it's an opportunity for the team to discuss what work is involved.

One person may have a more efficient way of doing things, or the other person may have a better understanding of the steps involved in doing the work. This discussion will help them share ideas, create a common understanding, build consensus, and create a more accurate estimation.

Compare this to estimating time. If you ask each team member to estimate the amount of time involved in a task, you’ll get 5+ different answers. Timing depends on experience and understanding. But most team members will agree on the effort required to complete a story, which means you can reach a consensus and move on with your story mapping or sprint planning much more quickly.

3. No artificial deadlines

Estimating time instead of story points forces you to come up with an artificial deadline, which can create unnecessary pressure (and probably won't be all that accurate).

Story points more accurately and practically reflect reality. In most cases, there is no set deadline - only ensuring tasks are done efficiently and in the right order of prioritization.

4. Better planning and forecasting

Story points can help you plan better in advance. For example, if you know that Johnny is going on holiday for a week, you can adjust your sprint so that your team doesn't over-commit. Or you can find another way to increase your capacity, like bringing on another team member or reducing scope.

5. Zoom in on the details

Story points force your team to think through the work involved in an upcoming sprint, and consider what's realistic. It's a time for your details-oriented team members to shine - and time for your big-picture thinkers to understand what needs to happen to bring their plans to life.

6. Get commitment

When your team knows they can achieve what's planned and they’re confident in their velocity, it's easier to get them to commit to the work and follow through confidently.

7. Be more adaptable

If the team size changes (maybe you add a new member or someone moves to another role), you have a built-in system to update your velocity (i.e. how many stories you can complete in a sprint) and adapt your workload accordingly.

8. Be just accurate enough

Story points help you estimate what your team can get done in a given amount of time. This kind of accuracy means smoother releases that go to plan - and is especially valuable when you have multiple teams with multiple dependencies.

But at the same time, story pointing makes it clear that your work is only an estimation, and you're not committing to getting X done in Y amount of hours. You won't know how long something will take until you do it - there are nearly always unexpected things that pop up.

Other methods might give you more precise timing, but it’s not practical to spend 30 minutes discussing the work that goes into every single story on your backlog. It’s much more practical to assign an “accurate enough” number, plan your sprint, and get to work.

9. Better capacity planning

You might not be able to fit all your top priorities into a release, especially if they’re complex, risky, or time-consuming. But story points can help you easily identify one or two smaller stories to fill your capacity every sprint or release.

Using story points also encourages you to find ways to increase your team’s capacity (rather than working longer hours). If you can mitigate risk, find ways to reduce effort, and bring the right people in the room to make complex tasks more simple… you’ll be able to get through more stories, more quickly.

10. Measure and improve performance

Story points can help you measure and improve performance by asking your team questions like:

• Did you complete all the work assigned during the sprint?
• Is your velocity going up or down over time, as you get better at agile?
• Was your story points estimate accurate?
• If not, how could you optimize your team's performance and ensure you work or plan better together?

Does everything in your backlog need user story points?

Some teams don't assign story points to every item in their backlog. They might just assign them to the user stories. They might avoid assigning user story points to bugs that come up during the sprint, particularly if they're not related to any of the stories originally mapped to the sprint. This makes sense since it's often tricky to estimate a bug - some take very little effort to resolve, while others are quite complex.

Your backlog might also include smaller jobs or technical tasks that would take anywhere from a few minutes or a few hours to complete. These tasks may not have story points assigned if they require very little effort.

But it’s important to note that these tasks still matter. They still deliver value back to the user. And they're essential as part of your goal: to deliver working software. But you can't always plan for them or estimate them ahead of time.

So, how do you incorporate them into your workflow?

You might need to discuss some different ideas and strategies with your team.

For example, you could set aside a buffer in your capacity to allow for an average amount of bugs and other jobs that don’t get story-pointed. That way, you can stay on track with the stories you have assigned to the sprint, while getting other items ticked off the list.

Either way, if your team is working on tasks that don’t have story points, you have to consider the impact on capacity. You will need to adapt, assess whether the sprint goal is still doable, and adjust your plans accordingly.

What happens if you get the estimate wrong?

While you should aim to make your user story point estimates as accurate as possible, you might have under or overestimated the amount of risk, effort, and complexity involved in bringing a story to life.

This might mean you don't get all the work planned for your sprint done. Maybe you need to move some of it over to the next sprint, which will mean reprioritizing and adjusting your user story map.

Fortunately, this process is pretty straightforward if you use digital user story mapping software like Easy Agile TeamRhythm.

Retrospectives or sprint reviews are a good time to discuss any issues with your team where estimates were off. Take some time to go through what happened, understand why more or less effort was required, and discuss how you might do more accurate estimates in the future.

Assign story points inside Easy Agile TeamRhythm

With Easy Agile User Story Maps for Jira, you can add and edit story point estimates directly on your story map. Simply select the story or issue and edit the story point field.

It will automatically update your sprint/version statistics with new totals, so you can see your capacity, arrange stories into sprint/version swimlanes, ensure you’re making the most of your velocity, and avoid over-committing.

Plus, your whole team has access to the user story board and estimates - perfect for in-house or remote user story mapping, online collaboration, and updating estimates at any point in the process.

Curious about Easy Agile User Story Maps? Features include so much more than story points, like:

• Drag and drop prioritization
• Visualized customer journeys inside Jira
• Sprint/version swimlanes for organizing stories
• Easily add or edit stories inside your story map
• See sprint/version statistics at a glance
• Easy collaboration with team members
  

Free Trial: Easy Agile TeamRhythm

One question that often arises is, “What are the indicators of a highly effective Scrum Master?" When striving to become an exceptional Scrum Master, consider the following:

• Identify Repeated Mistakes: While occasional mistakes are expected, it is important for the Scrum Master to collaborate with the team to identify recurring mistakes. By implementing policies and practices, the team can prevent these mistakes from happening again.
• Address Systemic Issues: If the team consistently encounters the same issues, the Scrum Master must recognize the presence of systemic problems. Working with the team, the Scrum Master can establish countermeasures to prevent these issues from reoccurring.
• Measure Improvements Over Time: Are we continuously improving as a team? Assess whether the team is more effective now compared to prior periods, such as 6, 9, and 12 months ago. Similarly, consider if the team will be better in the future. If progress stalls, it may be necessary to reevaluate the effectiveness of the Scrum Master.

If your team is progressing across all three of these areas, that’s a great sign that the Scrum Master is effective and that the team is learning and improving.

To drive continuous improvement, the Scrum Master should utilise the retrospective. The retrospective is a Scrum event conducted after the Sprint Review to evaluate and adapt the process and the team's ability to deliver products effectively. During this session, the Scrum Master guides the team in celebrating successes and exploring areas for improvement.

7-step checklist used by Scrum Masters during retrospectives to address problems:

1. Discuss the Problem: In the retrospective, the Scrum Master facilitates a discussion to identify the main challenges faced by the team.
2. Assess Impact: Determine the urgency and impact of the problem. Immediate action may be required for highly impactful issues, while less pressing matters can be addressed later.
3. Identify Root Causes: Understanding the root cause allows the team to gain deeper insights and generate potential solutions.
4. Generate Solutions: Once a significant problem is recognized, the Scrum Master guides the team in brainstorming solutions to address the issue.
5. Implement Solutions: This step is carried out in the subsequent retrospective. The Scrum Master ensures that the proposed solutions are tried and tested.
6. Evaluate Initial Results: Assess the effectiveness of the implemented solution. Did it fix the problem, make it worse, or have no effect?
7. Determine Next Steps: Based on the results, decide whether the problem is resolved or if further action is needed. This may involve continuing with the current solution or pivoting to a different approach.

For example, let's consider a team struggling with high defect rates. Their defect rates surpass both the organisation's average and industry standards. Here's how the 7-step checklist could be applied:

Step 1: In the retrospective, the Scrum Master raises the issue of high defect rates for discussion.

Step 2: The Product Owner shares feedback from the help desk team, highlighting customer complaints and the negative impact on sales.

Step 3: After deliberation, the team recognizes that many defects are missed during manual testing and identifies the lack of test automation as a contributing factor.

Step 4: A team member with experience in automated testing proposes implementing unit-level automated testing practices.

Step 5: In the subsequent retrospective, the team reports applying the new unit testing practices to all their work during the sprint.

Step 6: The team acknowledges that the automated tests identified six defects that would have otherwise been missed.

Step 7: The team agrees to continue using automated unit testing practices and plans to expand to integration-level testing as more of the codebase is covered.

By utilising this 7-step checklist, Scrum Masters can effectively leverage retrospectives to address recurring mistakes, resolve ongoing issues, and foster continuous growth and improvement within their teams.