What are Story Points?

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:

• Story Points and Estimation - By Dan Radigan
• 12 common mistakes made when using story points - By Maarten Dalmijn