What are Story Points?

Published: Feb 29, 2020 by C.S. Rhymes

I’ve always estimated development issues in hours or days but I recently created a new project in Jira and it only allowed me to use story points for estimates. I have always stayed away from story points as I have struggled to understand what they mean and why I should use them. But as the project only allowed me to use story points I thought I had better make a proper effort to learn what they mean.

This article is based upon my initial understanding and reading of other articles that I have also read. I haven’t yet tried this out but this is my understanding of how story points should be used.

If you have any tips from your own personal experience then please share them in the comments.

Comparing Time Estimates to Story Points

My first reaction was to search for a story point converter to convert what I would normally enter, say 1.5 days, into story points. This seemed logical to me as the idea is to work out what you can accomplish in a sprint and a sprint is a set amount of time, for example, two weeks, but the more I read, the more confused I became.

From what I have read, there is no direct mapping from a story point to time. In fact, a story point can vary between different teams and even different projects. Some teams can use a scale of 1 to 12, whereas others can use 1 to 5, or 1 to 100, or even their own scale.

So if everyone is using a different scale how can anyone know how long something will take to do?

Benefits of Story Points

The idea of using story points is to remove the idea of attaching a task to a due date or a time estimation. Whatever you estimate, chances are it will be wrong, so why not embrace that and instead, estimate based on the difficulty of the issue. It doesn’t seem to matter what scale you decide to use, as long as you use it consistently in your team.

How to estimate Story Points

Story point estimates need to be relative to other issues in your backlog, so if your team decides a particular issue is 3 points, then similar issues should be 3 points, larger or more complex issues should be more and quicker or easier issues should be less.

The whole team should be asked what their story point estimate is for a particular issue as any one of them can potentially be working on it during the sprint. It also helps get a more accurate estimate as one person in the team might see the issue as being very simple, but another person might know that the issue would also impact another part of the system, leading to more work than expected. For example, fixing the actual bug might take an hour, but the fix could also require tests to be refactored and user guides or documentation to be updated.

Learning from estimated Story Points

If you estimate an issue as 3 story points, but then realise that it is more like 5 then you should not change the estimate as this would then effect all of the other issues estimates. Instead, next time you have a similar task to complete you can argue that it should instead by 5 story points. You can use your experience to help improve your estimates in future.

Once you have completed your first sprint you can then look back and see if the total story points in the sprint was too high or too low. The amount of story points per sprint is known as the velocity. This can then help your team plan the next sprint by providing guidance of how many total story points you should aim for.

Getting Started

After all the research, I am now keen to start using story points to find out the benefits first hand over time estimates. I’ve bought a pack of agile estimation cards so each team member can pick a card with their estimate on and show it to the team, but there are also apps available if you prefer.

Articles for further reference:

productivity beginners agile career


Latest Posts

Mocking window.location in Jest
Mocking window.location in Jest

Recently I had to write some tests for a piece of JavaScript code that used window.location. This left me trying to figure out how to mock the window.location so that I could pass in dummy data and ensure that the data I got back was what was expected. Here was how I managed to solve the issue.

Considerations for Incremental Static Regeneration in Next.js
Considerations for Incremental Static Regeneration in Next.js

Next.js offers a feature called Incremental Static Regeneration (ISR) that allows you to generate a static page when the page is first visited, rather than generating a static copy at build time. This is a really handy feature as it allows you to reduce your build time, but still benefit from having a cache of a page generated so future visitors will have a faster response time.

Mocking axios in Jest tests with Typescript
Mocking axios in Jest tests with Typescript

Recently I wanted to write a test for a React component that uses axios to retrieve information from an API. To do this I had to mock jest, but I ran into some issues with the types as I was using typescript. This article explains how I managed to get it to work.

How NOT to make a website

How NOT to make a Website

By C.S. Rhymes

From £8.99

Nigel's Intranet Adventure

Nigel's Intranet Adventure

By C.S. Rhymes

From £2.69