Demystifying Story points

Most of the teams, I have interacted with, have a confusion of using story points vs person hours. With this article, I will try to demystify everything about story points.

What is a Story point

In simple words, its something decided and used by agile teams, to provide relative estimates of effort for completing requirements. They are intended to make estimation process easier. Instead of estimating it in hours, teams consider only how much effort a product backlog item will require, relative to other product backlog items.

If you ask two developers to estimate the same story, you’ll get two different answers. While some of the difference might be explained by gaps in the specification or understanding, the fact is that developers have different knowledge and experiences so it will take more or less time to do the same work. Now, ask those same two developers to rate the amount of effort required to complete one story relative to another story and they will likely to end up with a consensus.

As Jeff Sutherland, the co-author of the Scrum Guide mentioned: Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

Still, WHY do we need story points:-

• Non project related work like emails, meeting, tech sessions are never accounted using dates.
• Also, it seems that dates have an emotional attachment to them and relative estimation removes the emotional attachment.
• Each team have different velocity as they estimate work on a slightly different scale and which , in turn, makes it impossible to play politics using velocity as a weapon.
• Once team reaches to an agreement, you can assign points quickly without much debate.
• Story points keeps team members focused on shipping value, not spending time.

What Goes Into a Story Point?

Story points represent the effort to develop a story and a team’s estimate must include everything that can affect the effort including:

• The amount of work to do
• The complexity of the work
• Any risk or uncertainty in doing the work

When estimating with story points, be sure to consider each of these factors. Let’s see how each impacts the effort estimate given by story points.

For eg. consider a task of traveling from Delhi to Chennai. The duration of the travel depends on the mode of transport (Think mode of transport as the technology with Flight taking 3 hours and Car 36 hours). If you choose to travel by the road, your driver’s route knowledge (domain knowledge) is required to reach on time. Duration is dependent on multiple factors, but the distance is approx 3600 Kms which is constant and doesn’t change. Now, replace the distance with size. Size is easy to estimate, but not the duration.

How to use them

In most cases a story point uses one of the following scales for sizing:

• 1,2,4,8,16

• X-Small, Small, Medium, Large, Extra-Large ( known as “T-Shirt Sizing”)

• Fibonacci sequence: 1,2,3,5,8,13,21

Relative sizing process:

1. List all the stories to be sized
2. Put them in order from smallest to largest

Take the first user story
— Then take the second user story
— Decide which is bigger and put the bigger one above
— Then take the next one and decide where it fits relatively to the other two
— Then take the next one and do the same
— Repeat the process until all the stories are now in the list (in a sequence from smallest to largest)

3. Size the stories

Start from the bottom and give that story a number “2” story points. Giving ‘2’ provides you the room to give a smaller story ‘1’ if discovered at a later stage.

– Look at the next story and decide how big is that story as compared to the first one

– Continue until you have a size on each story

– Use these set of numbers [influenced by Fibonacci] while sizing:
1, 2, 3, 5, 8, 13, 21

You can also use T-shirt sizes XS = 1, S = 2, M = 5, L = 13 , XL = 20, XXL = 40

Few Myths about story points

a) Mapping Story Points to hours.

Story points should never be mapped to hrs as by that you are risking the commitment. By putting a fixed time like 10 hrs instead of taking range of 7–14 hrs, you are adding an incorrect accuracy as you start working with having fixed time deliverables in mind.

b) Using intermediate Story Points.

Lets take an example where half of the team estimates a story at 5 Story Points and the other half at 8 Story Points. It can be easily resolved by putting 6 as the estimate. This should not be done as the you need not to be 100% correct and you might lose a valuable discussion by averaging. Here, the better estimate is 8 Story Points.

c) Re-evaluating Story Point in running sprint.

Team should not adjust the Story Point estimate, once the sprint starts as it is part of the final sprint velocity even if this is inaccurate. It is OK that few times estimates may be off.

d) What about bugs

Any unrelated bug to the current sprint should be story pointed as it represents the work the team needs to complete. However, a bug introduced while working on a story in the sprint should not be story pointed as this is part of the original story estimate.

e) Developer competency

Story pointing should be done by the whole team as it can be a 2 pointer for a Sr. developer but 5 pointer for a junior developer. Team needs to reach an agreement here and points should not be adjusted based on as who is going to work on that story.