A Practical Guide: Story Points-Based Estimation

13 January 2014

Suman Guha
Red Hat Inc.

I imagine you have read many articles about story points-based estimation. Hence, instead of going over how it all works, I will try here to provide a practical guide for how to achieve it.

Before we start, I will assume you are already on a team comprised of at least these members (that is, a Scrum team): product owner, ScrumMaster, developers, and QA. The idea is to get the team to do a comparative analysis of all of the stories for the project. Let's take a look at the following steps:

Identify base stories
It is important to identify one or multiple base or reference stories against which you would do a relative sizing of the backlog. This story is picked from the current product backlog or is a different story that we have done earlier. But what is important is that the understanding of this story is same among everyone on the team. The team should be confident of this base story.

Walk through the requirements of the story
The product owner will provide explanations about what exactly the specific story entails.

Discuss and jot down any details you want to remember when implementing this story
These can be bullet points on the story card or text in the notes section of a tool. This is best done by ScrumMaster, who can add these details as and when discussions are going on.

Sample questions the team should ask (obviously this is a template, and this may vary based on your scenario)
Design: What will we have to learn before we can start work on this story?
Coding: What will be the likely coding effort? Has anyone from the team implemented it before?
Unit testing: Is any special setup required (e.g., mock objects) to unit test this story?
Acceptance testing: How much work is involved in helping the customer automate the acceptance tests for this story?
Integration points: Does the story have any external dependencies?
Expertise: Does anyone have prior experience?

If this story is about the same amount of work as one you have already sized, give it the same number of points. If it is more difficult, give it a proportionally higher value. If this story is similar to another but less work in some way, give it a lower value.

Reach a consensus
Consenting to a proposal of the size of the story as per Definition of Done doesn't necessarily mean it is your choice. Encourage the team to come up with the best estimation that, as a group, everyone accepts.

Validation of estimated story points
Validate that the estimates are internally consistent among stories as you go along. In simple words, the idea is to periodically ensure that all of the 1's are about the same, all of the 2's match. Likewise, the team should agree that a 4-point story is roughly twice as much work as a 2-point story.

This is a rough guide that has worked for me, and I hope it works for you too. However, the key to understand in story point estimates is that it does not matter if your estimates are "correct" or "incorrect" as long as you are consistent.

Article Rating

Current rating: 4 (1 ratings)


Elmar Jobs, CSP,CSM, 1/14/2014 6:57:02 AM
Nice article about the basic principles of story point based estimation. I'd like to emphasize a few points:

Finding a base story, a "stepping stone", is crucial for estimation. It is very tempting for the team to relate story points to hours (or days) of work. But thinking in real time units is very error prone. Looking only at relative sizes for stories helps to avoid this trap. A good way to do this is to attach each story after discussing it onto a board with columns denoting the different size in story points. By doing this one has a visual reference of the relative sizes of stories.

You are mentioning the DoD, which is indeed an important reference for the team to estimate the effort of a story. This implies that a clear DoD does exist (which often is a weak point) and that it is comparable between the stories to estimate. This might become a problem if the stories are very different.

Your last sentence is very important in my opinion. Story points are not right or wrong by themselves, as they are relative and approximate. They are there to help the team to discuss the effort to be put into a story, to get an idea how many stories of different sizes will fit into a sprint and to give the PO an estimate how long it will approximately (!) take to reach a specific point in the backlog. But often, story points are used by "the organization" to measure performance and to control the team. This will render them useless, as the team will adapt them to their external goals.
Michael Kuesters, CSM, 1/15/2014 6:46:38 AM
I can heartfelt agree that a fairly standard question catalog should exist when estimating Story Points.

I have a different opinion on Story Points comparison, however:
The standard planning poker doesn't have a "4" or an "8" - and doesn't even mandate that a "2" should be twice as big as a "1".
In fact, it goes by Fibonacci as opposed to Squares on purpose.

A "1" must definitely be smaller than a "2" and a "2" must be definitely smaller than a "3" - but it's not adding value to go into how much smaller a "1" actually is than a "3".

What we typically do, however: When a story gets bad numbers (20,40,100) then we already know it won't be easy to get "Done" and we "divide and conquer" until we end up with single-digit points on individual items.

You must Login or Signup to comment.