Story Point is a measure of relative bigness used by Scrum Teams mostly. They use this before the sprint starts to indicate and figure out how big or small a given feature is.
For example: If I were to list the following fruits and ask you to line them up left to right based on the complexity of eating the fruits and enjoying them how would you line them up.
Banana, Cara Cara , Apple, Pear, Mango, Grapes, Pinepapple.
You probably put grapes as the simplest as you tried to line up the fruits from simple to complex. Why Grapes? Maybe because its small, easy to wash, quick to eat etc.
Once you line them by complexity you can give any number sequence. Most teams tend to use a modified Fibonacci.
1, 2, 3 5, 8, 13, 20, 40 100. The unreal numbers 20, 40 100 signify the fact that when its is unknown it really does not matter. All we need to now is Cara Cara and Pineapple or really complex and not as simple as a pear or Banana.
It is a relative term and does not directly co-relate to actual hours. Since story points have no relevance to actual hours, it makes it easy for scrum teams to think abstract about the effort required to complete a story.
If you look at the Fibonacci curve it really takes a steep climb. If using this series consider not using 1 and 2.
Use 3, 5,8, 13, 20, 40,100.
But how do you know which story is a 3 and which is a five? In order to do that each team would have to find a baseline story. It does not have to be the smallest one, but one that all in the team can relate too. From then on all sizing should be done compared to that baseline.
This also creates a lot of confusion as most scrum masters who come from a PMP background relate this immediately to hours.
Story points do not relate to hours. So lets just not compare them. There is another technique called ideal hours which can be used.
Story points create lots of vagueness to your agile process. For every team, story size could mean different things depending on what baseline they chose. IF two teams are given exactly the same stories one can say their velocity is 46 and the other can say 14. Depends on what numbers they chose
So if you want to compare velocity between teams that’s a really bad idea as comparing velocity is like comparing apples and oranges. S o do not compare velocity across teams.
If you really have to track time then don’t use story points at all,A Use it for creating
- useful conversations in teams and not to get it right.
- Deciding when to split a story
- Negotiating with a product owner etc.
Be agile about story points. Use it for what its worth. It is error-prone and you can never get it right. The only time you will be right is once the work is actually done.
Agile Practitioners Guide 
Leave a comment