Why are story points estimates better than hour estimates?

Question that either you or your supervisor is always asking - “how long will it take you to do something” is one of the most important questions that comes with planning and decision making. Knowing how long your task will take determines what should be done now, what should be done later or what shouldn’t be done at all - it all depends on estimating.

In software development, there are usually two approaches that a team can take. First one is rather obvious - it is estimation in hours/mandays. In this approach after knowing what to do, the team will decide how long their task will take in hours. There is also another approach that more and more software developers use - estimation using story points. What exactly are those story points and what do they mean? Find out below!

What are Story Points?

Story points are basically units of measure for estimation purposes. Story points express the effort required to implement any piece of work.
So what does it mean in a real life scenario? Software developers can estimate their tasks not only based on one factor (which is time needed to finish the task) but many more. 

Examples would be:

• Complexity (how hard it is to implement/develop a new feature),
• Amount of work (how long it can take to complete the task. Remember - even when a task looks easy, it can be time consuming!)
• Risk of uncertainty (how unknown the task is). 

Teams usually use Fibonacci scale (ex. 1,2,3,5,8,13,21 points) in order to estimate the task by story points. What is 1, what is 2, and what is 13?

There is no strict definition of what they are - it depends on the team (some teams agree that a task that is estimated as 13 story points is big and some teams say that it is not that big - it depends on what people are working on the project). For example it can look like this: 

1 - this task is easy and understandable,

2 - this task is also easy but a little bit more complex than “1” (so it is bigger overall),

5 - this task might be bigger than 1/2/3, or it is not bigger but there is a slight risk of uncertainty,

21 - this task is very big or very unknown (and if possible it’s in the team’s interest to split the task into smaller pieces so developer’s can deliver smaller pieces one by one instead of bringing this one big task as a sole Sprint goal).

How does it help though? Over time, this estimation system helps the developers to decide how many story points (and therefore how many tasks) they can fit within one Sprint. 

Example

During Sprint 1 our development team delivered a sum of 35 story points in a single Sprint. After knowing how much work we delivered during Sprint 1, we can assume that for Sprint 2 the team is capable of completing 35 story points as well.

Sprint 2 showed us that we actually had some time left in Sprint 2 and we managed to do another task worth 3 story points - so our total story points completed for Sprint 2 was 38 story points.

In the Sprint 3 we delivered 34 points.

Knowing what value we delivered in Sprint 1 (35 points), Sprint 2 (38 points), Sprint 3 (34 points) we can already tell how much work we can take to Sprint 4 to deliver it successfully. In order to know the value, we need to add Sprint 1/2/3 values and divide the number by the amount of Sprint we had (3).

So in our example it will be:
(35 + 38 + 34)/3 = 37

What is the number 37 for us? It is our team's velocity - it is the number of story points that a team can have in the Sprint in order to complete the next Sprint.

How do teams estimate?

One of the most popular (and efficient) ways of estimating the task is by organizing a Planning Poker session. What is this Planning Poker and why is it so good?

Planning Poker is an exercise which is held at the Backlog Refinements/Sprint Planning Sessions. Each user is given a set of cards (e.g. from previously selected scale - 1,2,3,5,8,13,21 etc.). 

Then the team's facilitator (Scrum Master) is reading the story/task. Our example can be “As a user I want to log into the app via Facebook so I can access the app quicker”.

Each of the team members should pick one card from Fibonacci’s scale and put it on the table upside down. When all team members decide, they are allowed to flip the cards showing their picked numbers.

What if the numbers were all the same? Great! Then the task is understandable by everyone in the team and this estimation can be written down somewhere (Jira as an example).

What if the numbers are different? That’s also great! It looks like the development team has a different understanding of the task - let’s discuss the topic to make an agreement inside the team. 

Maybe one developer thought it is a task that can take “2 story points” because he/she didn’t think about something? Or he knows exactly what to do and is so skilled that this task is so easy for him?

Or maybe another developer thought this task is “a 13” because he didn’t think about some simple solution for the problem? 

The most important value while using this planning exercise is a discussion. Developers can exchange their opinions about this task complexity/size/uncertainty and they can understand better the situation they are in.

Why are story points better than hourly estimates?

Now you may ask - why don’t you use “hours” in this exercise? What’s the point of using those abstract measures instead of just estimating it in hours?

Example 

Imagine if you and your friend decide to go biking somewhere. You both like biking, but your friend is faster than you. He/she shows some point on the map and says “I can bike there in 1 hour”.

You know the route but due to the fact that you are a much slower biker than him and you know that this route can take you 2 hours (because it took you 2 hours each time you were biking there). 

And now we have discussion that goes like this:

• “1 hour!”,
• “2 hours!”
• “1 hour!”,
• “2 hours!”

It can go like this forever. You can make a compromise and make it 1.5 hours. And this is the worst thing that you can do. You have an estimation which is not good for each of you.

Finally you will say “This is a 10 kilometer track and I can bike it in 2 hours”. And your friend will say “This is a 10 kilometer track and I can bike it in 1 hour”. The thing is - you are both right.

You can ride this route in 2 hours and your friend can do it in 1 hour. When we are trying to put hourly estimation for this task it looks like we can’t - because you work at a different speed.

But if you take some abstract measure (kilometers in this example) - you can agree on that. You can both agree that your journey will take 10 kilometers. You are just different about how fast you ride a bike. 

And this is exactly what is the main story point value - they allow individuals with different speed and skill sets to agree on the topic.

Why are hourly estimates confusing?

Now that you know what Story points are and how they are beneficial for accurate estimations, let’s jump to another question - why are hourly estimates confusing and overall not good for estimating software development work?

In order to understand why hourly estimates are not necessary in the Sprint you need to know what Sprint really is. Sprint is a period of time (usually between one and four weeks) in which a certain amount of work (which is agreed with the Product Owner at the beginning of the Sprint) should be done.

While working with the development team, there should be a clear understanding on both the client's side and company’s side about how many people are working on the project in the full-time equivalent (40 hours a week).

If - for example - team agrees with both Client and Product Owner on deliverables for the Sprint, it will be clear on both sides that work in the Sprint should cover full time of the Sprint in order to meet Sprint’s requirements.

One great example why hourly estimates can be confusing is related to the Scrum as a framework. The main factor why Scrum is so successful as a framework is the fact that development teams are allowed to follow the rules of empiricism -  during a Sprint there should always be a place to have a meaningful discussion that allows those teams to improve.

When developers are forced to look only at hours that are left for this task to be finished, they aren’t thinking about improving the process and helping the team - their main focus is to finish their assignment so they can go to the next one. Instead of focusing on team goals (which is delivering agreed Sprint scope) they are thinking about delivering their small parts of the Sprint. 

By using story points as a team's estimation method, you’re making sure that all of the team members are focused on delivering Sprint goals by for example talking with the team members about possible issues they have in their tasks. This way, they aren't worried whether the task will take 2 hours or 3 hours because - all in all - the Sprint goal should be delivered at the end of the Sprint.

Conclusion

While hourls are still the simplest way to understand developers' estimates, story points provide more data than just raw hours and allow development teams to improve with each iteration. Working as a team can provide great value and therefore I highly recommend at least trying to understand the whole concept of this alternative way of estimating.

More about estimates and why they're usually inaccurate in software development projects here.