loading...
Cover image for What are Story Points?

What are Story Points?

chrisrhymes profile image C.S. Rhymes Originally published at csrhymes.com on ・3 min read

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:

Posted on Jul 1 by:

chrisrhymes profile

C.S. Rhymes

@chrisrhymes

Laravel PHP and Vue js developer. I’ve also created a couple of Jekyll themes

Discussion

markdown guide
 

Cool post, but I need to ask you an unrelated question. I use canonical URLs for my xposts but I don't see anything like the "Originally published at csrhymes.com on Feb 29, 2020" that this post has between the title and tags. I've seen a few authors that have it. How do you do that? (I'm pretty sure mine are working in general cause I see the HTML tag if I fetch the page, and Google search console also suggests they're working, so I'm not sure what I'm doing differently.)

 

Hi Ryan, my site has an RSS feed and I’ve connected it to dev.to in my settings. When I add a new post to my website it adds it as a draft to dev.to automatically. It sets the canonical url but I don’t know what else it does differently to generate the “originally posted at” bit.

 

Thanks for your answer! I will have to look into RSS.

 

Another key thing about story points (in addition to everything above) is that the range of story points tells its own story...

Typically teams will use a power-of-two (1, 2, 4, 8) or Fibonacci sequence (1, 2, 3, 5, 8, 13) to generate their story point range. The common characteristic here is that the gaps between the numbers get bigger as the numbers get bigger. This "increasing distance" characteristic is intended to shine light on the fact that estimation of bigger things gets much harder, so our accuracy is likely to be much lower. This means there's no point using 12 (in the power-of-two) or 16 (in Fibonacci) because we're inherently unlikely to gain anything from the implied extra precision.

A far better approach is to split stories down (across meaningful seams) and estimate separately. Many teams will refuse to work on any story with an estimate greater than 10, for example.

 

We as a team use both story points and time based estimates.

Stories are initially estimated in story points in order for a release and iterations to be planned, but then when we're down at the current iteration and have broken down the planned stories in to tasks we look to put a time estimate.

Time estimates are just that though: estimates not expectation.