Story Points in Agile

Agile has always focused on the collaborative ways of working, and the same principle is applied in the estimation. Over time, the teams have moved on from traditional estimation techniques like estimating in hours and using bottom-up and top-down approaches to new estimation methods like guessing the size of the ready-to-start piece of work.

In this article, we will be discussing all-around story points in agile.

video tutorial on story points in agile

Table of Contents:

  1. What are story points in agile?
  2. Agile story points estimation
  3. Agile story points Fibonacci 
  4. Capacity planning with story points
  5. Summary

What are story points in Agile?

Story points measure the size of a product backlog item (PBI). We can also say that the bigness of any PBI is measured using story points. The measure of a PBI is defined not just in how big the amount of work has to be done to get it completed but, other potential points like how sure and comfortable the team is around the solution, the environmental factors in favour of the solution, also add-in. Therefore, sizing is influenced by many factors like complexity, physical size, and risks involved. Story points work as the relative units of measure to derive the efforts required to say that a work item meets the definition of done.

To build a better understanding, let us take an example of a story that requires a custom help message to be entered in all text-boxes in 100 screens that the team cannot automate. Though this might be a simple task, since it has to be done on many screens, it is a big user story for the sprint and will be estimated large in terms of story points. 

Story points are relative as teams use previously completed story estimations and compare them with the new ones to derive the story’s size in story points. For example, a team might have worked on a search screen, and a similar screen is in an upcoming sprint. The story points associated with this new story will be similar.

Story points are efforts from the development team’s perspective to complete a particular piece of work.

Agile story points estimation

Agile teams, especially the scrum teams, have been using the story points estimation technique for quite some time and proven effective. Teams use story points to estimate the effort required to build a user story by assigning numbers to the associated story.

During the sprint planning meetings, teams generally estimate a user story by:  

  • Pulling up a story from the product backlog, preferably the most valuable one.
  • Comparing the story with the other stories build in the past and giving a number(estimate) to this new story.
  • Discussing among the team members if the estimate needs to be changed and move towards accuracy.

Agile story points Fibonacci 

There is no hard and fast rule as to what numbers should be assigned to the user stories. Estimating in hours or days may not work well for teams as it raises wrong expectations among team and stakeholders, leading to failure feeling if the work is not complete at that time.

Generally, the teams use the Fibonacci series to assign story points to user stories. Fibonacci is a sequence formed when each number is the sum of two numbers preceding it, starting from 0 and 1. 

The sequence goes like: 0,1,1,2,3,5,8,13……..but many teams use the modified version of the sequence (0, .05, 1, 2, 3, 5, 8, 13, 20, 40, 100).

Fibonacci series provide an exponential approach to sizing than linear. For example a user story size 21 is much bigger than a user story of size 2.

Teams use the Fibonacci series because agile teams are trying to be accurate and not precise when estimating.

Capacity planning with story points

A lot of agile teams are planning their capacity in story points. It makes sense to plan capacity in story points because these are the same unit teams are using to estimate their product backlog items and or work items.

It becomes a lot easier for the teams to plan capacity in story points because they are aware of their team’s velocity and can prepare the team’s capacity based on how many story points the team can deliver.

Let us take an example assuming a team’s average velocity is 50 story points for a 2-week sprint. Then in the next sprint planning team will pull up the stories, which sum up to a maximum of 50 story points. 

Let us take another example of an unusual sprint where one week is holiday time for the team. In that case, it becomes logical to plan for only 25 story points.


This article discussed what story points are in an agile environment and how it is extensively used in estimation and capacity planning. We also discussed how the Fibonacci series is related to story points.

We hope this article helped you to build a good understanding of story points in agile. Good Luck !!!

Scroll to Top