Why you should prefer story points over hourly estimations

StoryPointsVsHourlyEstimations

Every now and then people ask “What is a story point?” And then somebody gives the answer like “A story point in our team is about 3-5 hours work for one person!” Did you hear this as well? Or did you even give such an answer to other people? I did!

Are story points just similar than hours?

If story points and hours are similar, why do we then even need story points? You could easily calculate the hours from any given number of story points. And if that is possible, why do we even have story points in the first place, if they can be mapped to hours easily? Then we can just estimate with hours instead, without introducing another layer (of story points) on top. This just confuses developers and stakeholders, right?

Well, let me give you the reason why we need story points for estimations.

Each developer has a different set of skills and experience

It is quite easy to explain that you have different persons in a team and each person has a certain set of skills and a certain level of experience. I´m sure, if you are working in a team, you can think of a member, who has great skills and is fast, while another member is quite new and it takes him/her some time to complete tasks.

For example, let´s assume a developer, we call him Fastian, is able to finish a certain task in 2 hours, while another developer, let´s call him Slowden, will spend 8 hours to finish the same task. That´s simply because of the fact, that Fastian is faster, he has more skills and way more experience than our young, slow guy Slowden.

So how would you estimate such a task in hours? Is it 2 hours, because you assume that Fastian should pick it up, as he will be faster? Or you estimate 8 hours, because you want to do a pessimistic estimation to make sure the sprint will be finished. Or do you estimate the task with 5 hours, the average value?

It is quite hard to decide and you won´t get it right, unless you know exactly who will pick up that task. But forecasting for a whole sprint, who is going to work on which tasks is (under usual circumstances) impossible.

A story point has a different meaning for each developer

That´s exactly the point where story points are going to help you out. Story points solve the estimation problem of different levels of developer experience. For both developers the task will be, for instance, 3 story points. But these 3 story points mean something completely different for Fastian than they mean for Slowden. Fastian might be able to burn on average around 30 story points per sprint, while Slowden, the less-experienced developer, is able to deliver only a fraction of that. Still, for both of them the task is considered to be 3 story points – and both of them are going to estimate that task as 3 story points. So that´s a big benefit, isn´t it?

Let´s assume we have another task, which is about double of the size than the previous one. Then Fastian and Slowden will estimate that task as 6 story points (double amount of story points) – so they can agree on the same amount of story points.

It does not matter that the bigger task will take Fastian only 4 hours to finish and Slowden requires 16 hours to complete – it is still 6 story points for both of them, because the meaning of a story point is individual per developer.

So, the benefit of story points is that you can have one single “currency” within the team for estimating the effort it takes to complete a task.

About hours, story points and beer

Recently I met the guys from the company, where I used to work a few years ago, and we went together for a beer (well, not only one). We were of course discussing scrum related topics and I found out that they are using hourly estimations during sprint planning. Basically they estimate the effort for each task in hours of work. Then they calculate the capacity of hours for each person, for instance 8 hours for 10 days, and based on that they decide how much tasks go into the sprint. I asked them, whether it works out and if they are able to do a good planning based on that hourly estimations. Finally they had to admit that it almost never works out, and it is hardly possible to finish the sprint as originally planned.

The reason is that they have developers in the team with different set of skills and a different level of experience. There estimation was based on how many hours the most-experienced developer will require to finish the task. This didn´t work out, of course, because the less-experienced developers cannot keep up with the productivity of the most-experienced developer.

Around beer number 5 the guys decided to switch to story points for their estimations for the next sprint. I didn´t talk to them since then, but I am quite sure they were able to solve their problem with introducing story points (and some credits also go to the beer).

Why do we start with 3 story points?

If you are currently using hourly-based estimations and you are now convinced to introduce story points in your team, then you probably have following question: “How many story points do I assign to my initial task? A moment ago you assigned 3 story points to the first task. But why the hell 3? Why not 5, or even 20 or whatever?”

Well, that´s a very good question, thanks for asking. Let me rephrase your question a bit: “How do you choose a reference task?

Hm, that´s a whole topic by itself and I am going to have a new post next week about that. So, if you are interested, then leave me a comment and tell me about your experience with estimations.

Ok, that´s it for today, stay tuned and HabbediEhre!

1 thought on “Why you should prefer story points over hourly estimations”

Leave a Reply

Your email address will not be published.