Estimations in Story Points vs Hours – What to Choose for Software Development?

The development of software and mobile applications is classified as a complex domain in the Cynefin decision-making model. This means that we are in the domain of “unknown unknowns” and cause-effect relationships are only determinable for historical data.

Furthermore, we are in an environment of constant changes. Everyday, we gain knowledge and understanding about the problem we want to solve with the product. As a result, business requirements also change frequently.

How can we truly determine how long it will take us to work on a specific requirement?

Why can Story Points be the solution?

Before we answer these questions, let’s think about the purpose of estimating. What benefits does it give to us, and why are we looking for alternatives to hours at all?

What does “estimation” mean?

Often, an estimation is just another word for a “clever guess”. Based on what we know at the time, we approximate the effort that is needed to do something.

Why do we estimate?

For sure, there are plenty of reasons to estimate. However, there are three areas that arise most often:

• It helps to plan the work and decide how big a team is needed
• It helps to define how much money we have to invest in the project and what the potential release dates are
• It helps in measuring the productivity of the team (but not effectiveness)

What are the common problems with estimating?

• It is impossible to assign a specific hour value for the risk or unknown
• Estimates are sometimes understood as literal valuations, which often leads to an unwillingness to take responsibility for them, which often leads to an overestimation.
• Estimating something you do for the first time can inherently be inaccurate
• Everyone estimates differently. It is not always possible for the person who estimated to work on the solution as well.

What are Story Points?

“Story Points are estimates of effort as influenced by the amount of work, complexity, risk and uncertainty” ~M. Cohn

This abstract measure only allows us to compare the requirements with others on the same list, and implemented by the same team.

When estimating in Story Points, we assign values to the requirements corresponding to the Fibonacci sequence. Each number in the sequence is the sum of the two numbers that precede it. The sequence goes: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on.

Fibonacci numbers are often used because it suitably reflects the fact that uncertainty grows proportionally with the size of the requirement.

How does estimating in Story Points look like in practice?

Suppose we have several User Stories, for example:

• User Story 1: As a user, I can log in for the first time and change my password so I don’t have to use the default password
• User Story 2: As an admin, I can manage notifications that are sent to the users, to optimize conversions
• User Story 3: As a user, I can see details about my investments

When estimating User Stories in Story Points, teams often decide to play a game called Planning Poker.

How does Planning Poker work?

We use cards with numbers from the Fibonacci sequence on them. When the User Story is clear for everybody, developers choose the card and show them at the same time. Thanks to this, the answers of other developers don’t impact anyone’s own opinion.

If all the numbers on the cards are the same – we’ve got a ready estimation. If they differ then there is an opportunity to discuss why. Usually, the discussion engages developers that gave the smallest and the biggest estimation. Then they challenge each other, ask if they have taken into account all the necessary use cases, share their experiences, and talk about potential solutions. The round is over when everybody agrees with the chosen estimation.

The first estimated User Story becomes a reference point for subsequent estimates.
If we have agreed that the first User Story is worth, for example, 8 Story Points, then when estimating the next one, we wonder if it seems more or less complex than the previous one.

It may seem a little confusing at first, but it quickly gets in your blood.

Coming back to our example, when playing planning poker, we can decide that:

•  Story 1 is worth 8 Story Points
•  Story 2 is worth 13 Story Points, because it’s about 2 times more complex than Story 1.
•  Story 3 is worth 5 Story Points, because it’s definitely less complex than Story 2, and it’s a little bit less complex than Story 1.

In total, these three User Stories are worth 26 Story Points.

Why do we use Story Points?

• It helps to easily identify complex, risk, and labor-intensive requirements
• Story Points allows team members with different skill levels to communicate about and agree on an estimate
• Estimating new requirements is much faster

Can Story Points be converted into hours?

Unfortunately, it makes no sense. If you absolutely need information in hours, it is wiser to estimate in hours right away. Thanks to this, we do not spend time and money estimating Story Points, only to convert them to hours.

What are Story Points better at than hours?

To answer this question, I would like to return to the second point: Why do we estimate?

We estimate because:

• It helps us to plan the work and decide how big a team is needed
• It helps to define how much money we have to invest in the project and what the potential release dates are
• It helps in measuring the productivity of the team (but not effectiveness)

Story Points help us to approach the subject of estimation more empirically 

If we know that our team, in the previous sprint, completed User Stories valued at a total of 26 Story Points, we can suspect that in the next Sprint, if they have the same capacity, they can achieve a similar number of Story Points. And this makes planning much more predictable and easier. What’s more, if we have estimated all the stories needed for the publication of the new version, we can immediately see how many sprints we need to ship this version and have a return on investment.

Estimates that use absolute measures, like time or money, will probably cause the final estimate to be rounded to the nearest tens, hundreds or thousands. So it still doesn’t give us 100% accurate information. Hours completed in the Sprint don’t tell us anything about how many User Stories/functionalities we can ship and when we can do it.

Due to the fact that Story Points cannot be translated into hours, we do not attach any specific value to them and we do not make important business decisions based on untrue data from the very beginning. We pay attention to the historical data.

Estimating hours takes much more time to do. Even so, we don’t have any guarantee that these numbers are accurate.

Because my hour isn’t the same as your hour

If you ask two developers to estimate the same task, you’ll get two different answers. And this is normal, as we all have different life experiences and perspectives.

Story Points take into account that several people need to collaborate to deliver functional value to the user. When estimating Story Points, we take into account the efforts of programmers as well as the likes of designers and testers. Some tasks may seem simple to code, but have a lot of test cases to verify. Story Points do not focus on how much time each team member will need, but how much effort is needed to deliver full functionality.

Summary

Hours are great for pricing simple tasks and repetitive activities. In software and app development, such tasks almost never appear. Each product is unique in its own way. Technologies and the market are constantly changing. People cannot predict the future 100%, but they can guess, then see if they have succeeded, and draw conclusions. Story Points support this empirical approach and help teams focus on delivering functionality. Ultimately, that’s what it’s all about!

Related posts