Shortcut Guides
Agile Software Development

What Are Story Points? Definition, Benefits, and Estimation Guide

Work sizing with story points helps Agile teams estimate task complexity, set realistic deadlines, and allocate time for risks and emergencies.
Dana Brown
Head of Marketing
Updated on
November 21, 2024

ARTICLE CONTENTS:

Join our Slack!

Ask questions, get answers, chat with other Shortcut users.
Try Shortcut for  Free 🤩 
Experience the most enjoyable, powerful way for your team to work.
Get Started Now

Proper work sizing plays a crucial role in ensuring efficiency in Agile projects. Estimation gives the team a clear picture of how much work they must do, allowing them to pace work, set realistic deadlines, and allocate time for emergencies and other risks. 

One of the best ways to estimate work in Agile is to assign story points — which are point values that denote a task’s level of complexity. 

Let’s discuss Agile story points in greater detail below. 

In a nutshell:

  • Story points are point values that represent the complexity of a user story, task, or feature in relation to other items in the backlog
  • The key metrics used to measure story points are volume, complexity, and risk
  • Story points alleviate a team’s fear of time commitment, encourage collaboration, and provide flexibility

What are story points?

Story points are point values assigned to user stories to denote complexity. The story point system helps teams understand how much effort is required to complete a task. Story point values typically account for work volume, complexity, and risk. 

Estimating story points typically happens during sprint planning meetings to help teams determine how much work they can squeeze into an upcoming sprint.

Story points are relative. There is no universally accepted standard for which point values equate to which level of complexity. The flexibility allows you to customize story point values according to your team’s needs and level of expertise. 

What are the key metrics used to measure story points?

Story points are not measured in complexity alone. You also need to factor in the volume of the task and the level of uncertainty involved to get a clear picture of how much effort a task will require. 

Volume

Volume refers to the amount of work available. It asks the following questions:

  • How much work needs to be done?
  • What is the size of the required work?

Let’s say you want to create a video demonstrating your software’s most essential features. While the task doesn’t require much brain work, it can be considered high-volume if you have many features to record.

Complexity

Complexity refers to how difficult it is to complete a story. Questions to ask include: 

  • How easy or difficult is it to meet the story’s requirements?
  • Compared to stories of the same volume, how complex is the work?
  • Is the story dependent on other stories?
  • Do other stories depend on this story?

Let’s say you have two items on the backlog. One is creating a user flow for your software, and the other is designing a wireframe. You might assign a higher point value to designing a wireframe since the process is more complex and semi-dependent on the completion of the user flow. 

Risk

Risk refers to the amount of unknowns that could affect workflows. When evaluating risk, you might ask:

  • What are the known unknowns?
  • What factors are uncertain?
  • Do you have experience with similar stories?

Here’s an example: the current task is to test the software’s UX. While your team provided the backend code, you outsourced the UI design to a contractor. Since you haven’t worked with this contractor before, risk increases.

The risk decreases when most elements are familiar. For example, if your team is used to addressing a specific type of bug, the story points allocated for fixing that bug would be lower. 

Story points vs. time-based estimation

Because everybody works at a different pace, time cannot be used as an accurate measure of productivity. Usain Bolt can cross 10 meters in one second, but a snail cannot. 

Similarly, your senior developers might work faster than entry-level hires. If you estimate a task will take a day, both will feel pressured to meet that expectation, regardless of their experience levels.

The senior developer might be forced to slow down, while the entry-level hire will struggle to catch up. Neither is conducive to efficient workflows. With story points, you measure complexity alone, allowing team members to estimate their hours based on their unique work styles. 

Benefits of using story points  

Story points are a popular method of work estimation for a reason. Below, we’ve listed a few of its most significant benefits.

Alleviates fear of commitment

Time estimations come with emotional attachment. Estimating complexity through hours sets a standard for how fast the work should be done. If the team provides an estimate of five hours for a task that eventually takes them ten hours to complete, they would likely feel that they fell short of their goals. Story points measure complexity without setting expectations of speed. 

Encourages collaboration

Deciding on the story point value of a product backlog item is a team effort. 

If a senior member assigns a story a lower story point value than a junior team member, they will come to an understanding of each other’s view of complexity. This will allow them to discuss the work in further detail and come up with ways to accommodate each other’s expectations and needs. 

Provides flexibility

Story points are relative. Estimations of complexity differ from organization to organization. You can adapt story points to accommodate your team’s needs. 

For example, you can build the confidence of a new team by valuing story points according to their skill set. This way, they'll feel more accomplished when they complete stories with high story point values. 

As they gain tenure, you can lower story point values for stories similar to past work items, thereby challenging them to surpass prior limits. 

How to implement and estimate story points

Transitioning your team into story points for estimation requires much preparation and onboarding. We’ve provided a step by step guide to implementing the story point estimation system. 

Step 1: Set a story point scale 

The first step in implementing a story point system is determining your scale. This is the sequence of letters or numbers that you will use to denote complexity. Common types of sequences include finger counting, the Fibonacci sequence, modified Fibonacci, powers of two, and t-shirt sizing.

Five fingers

1, 2, 3, 4, and 5

Fibonacci 

1, 1, 2, 3, 5, 8, 13, 21, and 34

Modified Fibonacci

0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, and 100

Powers of two

1, 2, 4, 8, 16, 32, and 64

T-shirt sizing

XS, S, M, L, XL, and XXL

Default Shortcut sequence

1, 2, 3, 5, and 8

Finger counting: Finger counting is a basic sequence that uses a scale of one to five to denote complexity. Its intuitiveness makes it suitable for simple projects. However, five might be too small a number for projects with more variety in product backlog item complexity.

Fibonacci: The Fibonacci series is a mathematical sequence of numbers in which each number is the sum of the preceding two numbers. The sequence is commonly used in Agile because the large differences between numbers help delineate higher levels of complexity. 

Modified Fibonacci: The modified Fibonacci sequence replaces Fibonacci numbers with 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, and 100 for simplicity. Using multiples of 10 makes later numbers easier to memorize. 

Powers of two: The powers of two sequences multiply each number in the series by two. Like the Fibonacci sequence, this creates precise delineations between low-complexity items and broad delineations between high-complexity tasks. 

T-shirt sizing: This method is best for teams that want a visual rather than a numerical understanding of complexity. The lack of numbers helps teams not get caught up in exact values and instead think of complexity relative to other estimated items. 

Default Shortcut sequence: The recommended Shortcut story point scoring system uses the numbers 1, 2, 3, 5, and 8. Stories exceeding a complexity value of 8 must be broken down into smaller parts. 

Step 2: Build a story point matrix

A story point matrix clarifies what each number (or letter) means. It is a scoring rubric that establishes a team-wide agreement on how to estimate tasks. Below, we’ve provided an example using the shortucounting sequence. 

Story Point

Amount of effort required

Complexity

Uncertainty

1 Minimal Very straightforward Very low
Example Copy change in a place where the team has changed copy before.
2 Minor Straightforward Low
Example Creating a new tracking event in the system.
3 Moderate Medium Medium
Example Returning a new response in a payload for the frontend to consume, in an API the team has worked in before.
5 Major Complex High
Example Building a small feature in a part of the code that the team may be unfamiliar with.
8 Maximal Very complex Very high
Example Building a feature in an area of the code the team is unfamiliar with or that may have dependencies with other squads.

Choosing more extensive sequences allows you to create more matrix categories, accounting for slighter nuances and task complexity. 

You can edit the matrix as the team gains hands-on experience. Through repetition and practice, some tasks will feel more straightforward. 

Step 3: A planning poker meeting

Planning poker is a technique that helps teams arrive at a unified conclusion for story estimation. 

During planning poker, the product owner facilitates a team discussion on story points. It follows the following steps:

  1. Each team member has a deck of cards displaying your chosen story points sequence. For example, a team that goes by the Shortcut sequence would distribute decks containing cards labeled 1, 2, 3, 5, and 8.
  2. The product owner describes a feature or user story to the team.
  3. Team members discuss the feature in detail to create a clearer picture of complexity, volume, and risk.
  4. Once the team is satisfied with the feature discussion, each member must select the card that aligns with their story point. For example, a member determines that the task of coding a new feature from scratch warrants 8 story points.
  5. All members reveal their cards at the same time. 
  6. If all members hold up the same card, the estimate becomes official.
  7. If there are differences between estimates, the discussion must start again. Team members share the reasons behind their selected estimate. 
  8. After the discussion, team members re-select estimates.
  9. Team members reveal their cards again.
  10. Steps 7 to 9 repeat until the team arrives at a uniform decision. 

Step 4: Implement story points in sprint planning 

Once you’ve scored all relevant features, you can incorporate your estimates into sprint planning. The story points will help you estimate how many items you can squeeze into a single increment. 

Step 5: Discuss story point changes sprint retrospective

On the first sprint, it might be challenging to determine how many story points your team can complete. That’s why story points should always be topics of discussion during sprint retrospectives.

During the sprint retrospective, make sure to study how much your team was able to achieve. Then, you can use that data to adjust the story point matrix or modify how much work you assign per sprint. 

Story point estimation best practices

Here are a few strategies you can use to maximize the impact of story point estimation. 

Split complex items

No matter your chosen sequence, it’s best not to let story points get too high. Once an item is too complex, break it down into smaller tasks. The Shortcut sequence, for example, ends at 8 to discourage items from getting too complex. 

Breaking down complex items ensures your team never bites off more than they can chew, preventing burnout. It also allows them to stay focused on an achievable task. Plus, ticking off the smaller items gives them a sense of accomplishment, which adds to their motivation. 

Get acceptance from the whole team

Everybody on the team needs to be on the same page about complexity. The story point matrix will help clarify the standard, while planning poker meetings ensure complete alignment. Team-wide acceptance proves that you respect all work styles, which increases motivation, independence, and accountability. 

Estimate based on past data

When the team scores stories too low, they might find themselves working on tasks that exceed their capacity. The miscalculation leads to missed deadlines and lost motivation.

Meanwhile, when the team scores stories too low, they might tackle fewer items in the sprint, leading to missed opportunities and slower releases. 

To maximize workflows, incorporate story point discussions in sprint retrospectives and recalibrate based on data. 

Summary 

Estimation lays the groundwork for upcoming sprints. Accurate estimation ensures that you tick off product backlog items within the expected timeframe.

However, using time-based estimations sets suffocating expectations on Agile teams. It forces team members to finish work at a specific pace regardless of their experience or work style. 

Story points afford teams more flexibility. They paint a picture of relative complexity while giving teams the freedom to work at their own pace.

With a project management software, you can seamlessly incorporate story points in your product backlog. Shortcut’s backlog management tools make story points a natural part of each product backlog item, encouraging you to consider accurate estimation whenever you work on a project. 

Read the Shortcut pricing page to learn more about our product. 

Share this article: