The definition of story points is not obvious.
Many scrum teams use story points in their daily job, because they are better for estimations than hourly estimations for many reasons.
But it is not clear how a story point is defined.
If you ask google, then you get a couple of different definitions.
Actually, I recently attended a conference in Amsterdam, the LeaseWeb Techsummit, and there I was listening to a talk from one of my coworkers, Arnoud.
The title of the talk was Scaling our engineering department, in which he talks about the agile transformation of our company LeaseWeb.
I really liked the talk and you should definitely check it out.
But there was one thing, which made me thinking – he specifies story points as a number based on the complexity of a user story.
I had a nice discussion with him and also other scrum masters afterwards.
But in the end it was not completely clear, how a story point is defined. That’s what triggered me to write this post.
I found two descriptions on the Internet, which I want to discuss here.
First description from agilefaq.wordpress.com:
In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, unknowns and effort.
So there they talk about complexity, uncertainty and effort.
And here the second description from Mike Cohn:
Story points are about the effort required to develop a feature.
Mike only talks about effort.
Let’s have a detailed look at the first, then the second description.
Complexity, uncertainty and effort
I want to discuss these three properties in more details.
Complexity
Story points are NOT about complexity.
To make that clear, let me reuse a wonderful example, which Mike pointed out in one of his older posts. Think of a difficult task, like a brain surgery and a simple task, like licking and putting 1000 stamps on letters.
Both of them take the same amount of time. In case you don’t think so, you can adjust the number of stamps to put on the letters.
If they take the same amount of time to complete, then both of them are going to have the same amount of story points, even though the brain surgery is obviously much more complex then simply putting stamps on letters.
Therefore story points do not have anything to do with complexity.
Uncertainty
We use story points for estimations of the size of a task.
If we exactly know how big a task is, then we would not have to estimate it.
Or let me rephrase that: If there is no uncertainty in the size of a task, an estimation would not be necessary.
Therefore it is obvious, that estimations contain uncertainty by its nature. But story points do not.
Story points are all about effort and only about effort
If you think about complexity, then most of a time a complex task takes longer to finish compared to a simple task.
Therefore more complex tasks usually have higher amount of story points. But this is not because of the complexity itself, but about the higher effort.
On my opinion you can actually derive the effort from complexity.
And the same also goes for uncertainty: you can derive the effort from uncertainty.
But at the end it all points down to one thing: story points are about effort and only effort.
Relative estimations
There is one more important thing:
When you estimate a task then you should estimate it relatively to a previously estimated task.
For instance, when you estimate a new task then you might think: “Hmm, that’s a bit less effort than the reference task. And, the last time we called the reference task 5 points, so this task is only 3 points.”
The key with story points is that they are to be estimated relatively each time.
Therefore you need to have a reference task before you start estimations with points. If you don’t have that yet, then have a look at my post on how to choose a reference task.
Conclusion
Let me wrap it up:
So, story points are all about the effort.
Feel free to adjust your estimate of effort based on things like uncertainty, complexity, risk, etc.
But in the end story points are only about the effort involved to finish a task!
Let me know what questions you get about the definition of a story point. And let me also know in a comment how you answered those questions.
That’s it for today, take care and HabbediEhre!
I find it interesting that you link to an article from Mike that you use as the basis for your assumptions, yet if you read his article it contradicts yours. In the section where he talkes about complexity he states – “So complexity is a factor in the number of story points assigned”, clearly indicating that complexity should be considered when assigning points. He goes on and talks about the other points as well.
If all you are interested in is effort then why use story points at all? Why cloud the issue if the team can just provide you with hours to complete a task. This reminds me of those Scrum Masters who tell me that 1 story point is half a days work, 2 a days work, 3 half a week and 5 a week etc.
I disagree with your reasoning about factoring uncertainty and complexity out of the story point definition.
Complexity: while it might take the exact same amount of time to perform brain surgery and applying 1k stamps the competencies involved are not the same. While most of us might be able to accomplish the latter we would probably end killing somebody performing the former. We should factor into the story point the effort required to build the skills necessary to accomplish the task and that depends on the skills available within the development team. Since not every member will have the same competencies having a team of fast learners will reduce the impact of complexity on your estimates.
Uncertainty: you are dismissing this too easily IMHO. Everything is uncertain, the only true fact is we will all be dead one day or another. That does not mean everything has the same degree of uncertainty: I’m pretty certain I’ll not be a billionaire next month, also I’m quite certain I’ll still be alive (hopefully). We must factor in our degree of uncertainty in the story point, not because EVERYTHING can happen, but because we don’t know if SOMETHING can happen.
Hi
First of all, thank you for your comment and sorry for the late reply.
Complexity: I agree with you that the level of skills should have an influence on the estimation. You even say by yourself that “we should factor into the story point the EFFORT required to build the skills”. That´s exactly what I mean: you can usually derive the effort from the comlexity, but not always – therefore effort is the better measurement on my opinion.
Uncertainty: I partially agree with you here too – we must factor the degree of uncertainty into our estimation. And yes, there are tasks, for which the level of uncertainty is a lot higher than for other tasks. In such cases the team can go for an estimation assuming everything works out perfectly well, or the team can estimate assuming the worst conditions, or anything in between. If the team is doubting I usually advice to go for a “conservative” EFFORT estimation and let the team decide what “conservative” means for that task.
Uncertainty can also be a matter of familiarity. If a brain surgeon is performing a very complex but routine operation, it’s very complex but there is little uncertainty. On the other hand, as an engineer working on a legacy system with literally millions of lines of code, sometimes something that looks simple means hours and hours of digging around in code to fill in the uncertainty. Some members who’ve been around longer are going to see less uncertainty but maybe everybody agrees on the complextiy.
I don’t think there is a one fits all model for points. I do think that everybody is racing toward making everything a 1 and in my experience almost NOTHING is ever a 1.
That’s cleared my thoughts. Thanks for cotgtiburinn.