In my last post I referred to the myth that Scrum Masters can make themselves redundant, the other most common and persistent myth I regularly hear is that Story Points are a measure of complexity.
No, no, no. Story points are just about relative size. That’s it, nothing more. There really is nothing complicated about it.
It is all relative
A small ‘simple’ task is not the same as a large ‘simple’ task. And a small ‘complex’ task that I can have done in a quarter of the time of a large ‘simple’ task does not warrant a higher story point estimate. It makes no sense to estimate that way.
My advice when estimating stories is to pick a cross section of stories, pick around a dozen typical stories of varying: scope, sizes, complexity, uncertainty, and any other factors that might affect the time and effort involved. Discuss them and get a feel for the stories and then sort them smallest to largest.
Next take a story in the middle and stick it in the middle of a white board on a horizontal line drawn across the board. Next take each story and estimate how much effort relative to the stories already on the board mark each story on a number line, hopefully you will get a flow after a while. E.g. The next story is 3/4 the size of the first so i put it 3/4 of the way between the end of the line and the first story.
When all your stories are on the line pick a scale that you think looks right. Just Try it and see, each set of stories will have a different distribution, if you initially pick a number too low and things feel squeezed, just try again. E.g you pick the story in the middle and using Fibonacci numbers call it 13pts where does this leave the rest? Do they fall easily into other Fibonacci numbers? stories around a 1/4 the size of the first would be a 3 and so on.
That is now your scale, and regardless of how your definition of done changes, or the team changes, the relative scale remains.
If you are lucky enough to have a team room with space to leave those stories up on the wall on the scale line that’s great, if not then take a picture. From now on when estimating any story you can say how does it compare to ‘x’, x was a 13pts and this is similar, or this is 50% bigger than ‘z’ and that was a 3 so this is a 5pts. By keeping everything relative to the initial stories and you keep the estimates consistent.
But what about complexity?
Complexity, and uncertainty, or time consuming interactions between layers or departments are all just considerations that affect the size. “That task is complex it may take me a bit longer”, “That task is unclear I’ll need to take some time to understand this aspect of it – it will take longer” all we are saying is that it is just relatively larger, there is no trick to it. It might help make life easy to say – this story looks very similar to 5-point story ‘x’, but has some uncertainty (or I’ll need to liaise with another department) therefore we’ll estimate an 8. It is the fact that complexity adds time that makes it a bigger estimate not anything else, it is just another factor in comparing the relative size.
Comparisons are so much easier than raw estimates.
When estimating new stories all you have to do is pick a story and say: “will this take longer than reference story x?” or “will it be less than reference y?” with enough reference stories there should be a suitable comparator to find a similar sized story and give it the same points value or a bit more or a bit less based on a considered factor. After very short time you will instinctively know the scale and estimating becomes quicker and easier. Your refining becomes a series of comparisons e.g. “this involves more testing than story x” or “it is like ‘y’ but with a bit more to the UI” etc. Comparisons are so much easier than raw estimates.
What about ideal hours or ideal days?
Some teams use ideal days or hours for estimates but that is subject to change according to the team, the team changes and the estimate changes, what if someone is off sick or on holiday? and more confusingly it implies a commitment to a particular amount of effort, what if your DoD changes and suddenly you are writing automated regression tests for each story, suddenly the scale us blown, but a relative estimate is always relative.
Sometimes after a while teams begin to drift, it may be worth having a refresher of the initial stories and initial estimates just to calibrate your estimates periodically, maybe even add new reference stories to keep the scale fresh.
Just remember it is all relative
Just remember it is all relative, and then it is easy!
John Yorke 
One thought on “The Confusion Over Story Points.”