What are Story Points in Agile and how do you calculate them?

Do you want to know the points of the Agile story?

Story points can sound like a reward you get from playing a fantasy video game.

But they're not!

Story points are an agile estimation technique that provides a relative estimate of how much work and effort will be required for a specific task.

But the problem is that, although the Agile guide tells us to make these estimates, it doesn't specify exactly how to make an estimate.

But don't worry.

In this article, we'll demystify story points and also talk about how story points are calculated in Agile. As a bonus, we'll let you in on a secret to help you implement story points effectively in your Agile development projects!

What are story points in Agile?

Before we talk about what a story point is, we need to understand two terms: 'user story' and 'product backlog'.

A user story is an informal explanation of the features your user wants in the system.

An example of a real-world user story is: "As a player, I want my hero to be able to fly".

But wait, where does the user story fit into the Agile development process?

It fits into the product backlog.

A product backlog contains a list of all the user stories that need to be worked on and implemented in the final product.

Think of it this way:

User stories are items in your video game inventory, such as magic swords, armor and other cool stuff. The product backlog is the inventory that contains the items!

So now, let's get back to the story.

A story point is a unit assigned to a user story to express how much time and energy would be required for that job.

It's like the difficulty level of a game.

A higher number means a more difficult level.

However, this is where most people go wrong.

In a video game, level 2 doesn't necessarily mean that it's twice as difficult as level 1. But that's not the case with story points.

Let's explain:

Story points are a relative estimation technique (also called relative sizing).

Relative estimation means that values are assigned on a comparative basis. This means that there are no standard units for story points.

For example, if a user story A has a score of 2 and a user story B has a score of 1, this means that A will take twice as much effort to complete compared to B.

However, video games and story points have one similarity: landmarks.

For example, let's say two teams are building two similar mobile puzzle games.

Level 10 in the first puzzle game wouldn't necessarily be as difficult as level 10 in the second puzzle game, right?

Similarly, your team can assign a story point value of 8 to a user story and another team can estimate 13 points for a similar story. The value of your story points depends entirely on your team and your task.

Why use story points in Agile?
We know what you're thinking.

Do we really need to use Agile estimation methods as story points?

Can't we just use time estimates?

Well, you can, but the story points are a much more accurate estimate.

Story points allow you to calculate the team's speed and estimate the workload objectively.

1. Team speed can be calculated
The speed of your team is an important metric that you simply can't ignore.

Why?

By calculating your team's speed, you can visualize it:

efficiency of your Agile team
how fast your Agile team is progressing
This way, you can make better predictions for your future project schedule.

But what is speed?

The velocity (also called sprint velocity) shows the amount of work that has been done in each sprint. It is the total number of story points completed divided by the total number of sprints.

For example, let's say your team finishes 50 story points in 2 sprints.

So your sprint speed will be (50/2) = 25 points per sprint.

2. Estimating without specific time commitments
Things don't always go according to plan, even in an Agile project.

And when you're using a time estimate, you're only specifying an approximate time. You can spend more time on tasks that you thought would be completed in an instant and vice versa.

The main point is that it is difficult to estimate the exact amount of time needed for a technical task.

As story points are an agile estimation method, they don't make any definite commitments (such as within a week or next Friday). Instead, they provide a relative estimate of the overall effort that will be applied to a task.

This will help reduce the unnecessary stress of meeting tight and unrealistic deadlines. Instead, you get a much more reasonable and accurate estimate.

3. Story points are not subjective
Sometimes people differ in their estimates of how long a task will take in an Agile project. This often leads to subjectivity when using time estimates.

That's why this approach doesn't always provide an accurate estimate.

For example, a senior developer may assign a task of '7 hours' according to your standard, but it may take a junior developer 15 hours to complete the same task.

Story points eliminate this problem.

When calculating an Agile story point, the whole team sits down and decides which points to assign to the user story.

Bonus: check out our guide to agile launch planning!

3 key factors affecting story points in Agile
So, we talked about assigning the user story according to the 'effort' required to implement the backlog item.

But what exactly does effort mean?

Let's take a look:

A. How much work needs to be done ( story size )
Not all backlog items are equal; one item in the product backlog may require more work than another.

For example, suppose there are two different backlog items:

'I want a new weapon for the main hero, Monkey King'
'I want new weapons for all the heroes'
Which do you think will take longer?

The second story, of course!

Compared to it, the first story won't be much work.

Therefore, the second story will receive more points than the first due to the longer length of the story.

B. Risk and uncertainty
Every project has its risks and uncertainties, especially with certain types of outstanding items.

For example: if the product backlog item involves working with a new structure that your team doesn't have much experience with, this risk factor will increase the value of the story point.

C. Complexity
Complexity is definitely a very important factor for any Agile estimation technique.

Here are two similar stories with different acceptance criteria:

'I want a new outfit for Geralt'
'I want a new special attack for Geralt'
Notice the difference in their complexity ?

The first is a piece of cake, just a few tweaks here and there, and that's it!

The second requires you to code a new special attack and see how it works in the game.

Then you'll have to test for bugs.

Naturally, during the effort estimation process, these user stories clearly score more points.

Bonus: check out our guide to Technology Debt!

How Story Points are calculated in Agile
You can calculate Agile story points by creating a base story, choosing your scale and estimation technique and calculating accordingly.

Estimating the story point is usually done using a method called 'planning poker'.

Sounds interesting, right?

Let's now learn how to estimate a story point:

1. Create a basic story
Set up the poker table

The first step in the estimation technique is to create a reference story or baseline story.

It is a completed user story from a previous iteration cycle assigned a story point value (usually 1 for simplicity).

This will be your standardized history point.

The product backlog is also displayed with all the new user stories.

2. Choose a scale for estimation
Deal the cards

There are two scales used to estimate story points:

Linear scale: contains natural numbers such as 1, 2, 3 and so on
Fibonacci scale: numbers from the Fibonacci series such as 1, 2, 3, 5, 8 and so on.
For simplicity's sake, most agile teams tend to choose the Fibonacci series for their estimation of story points.

In this estimation technique, the Fibonacci scale is then entered into a table where you can assign any user story to a value.

See how an estimation table looks when the team starts filling it in!