Story Points vs Hours: 4 Reasons to Estimate with Story Points

Story Points are a handy and efficient measurement technique for estimating the amount of effort a team needs to develop a particular feature. If you want to know what advantages estimating in Agile Story Points has over estimating in hours, go on reading this article.

Man-Hours: What Are They and Why Don’t They Work for Us?

Estimating in man-hours is one of the most widespread approaches for measuring team work. It relies on an estimate of the amount of work that can be completed by one person within one hour. While man-hours are easy to understand, there are a few big drawbacks to this technique:

• Some tasks are difficult to estimate precisely
• If one developer estimates a project but another completes the task, the estimate becomes invalid. The time needed to complete a task will vary based on a developer’s level of experience
• People generally underestimate obstacles they might face and consider only the best-case scenario

The bottom line is that drawbacks of estimating in man-hours outweigh the advantages and bring value neither to RubyGarage nor to our clients. But there are multiple reasons why we like estimating in Story Points.

What is a Story Point and how to use it to estimate your project

A Story Point is a metric used in Agile project management and software development to estimate the difficulty of implementing a particular User Story. Story points are typically a unit of measuring three things, that each work item consists of:

• The amount of work to do
• The complexity of the work
• Any risk or uncertainty in doing the work

The Story Points approach is based on comparison of features of one project with features of a previous similar project. The comparison allows the team to understand the difficulty of a particular feature and lets them assign a numerical value that indicates its complexity. 

In case the estimation is performed for the first time and there’s no User Stories to compare with, a team needs to identify a Base Story and create a Matrix for Estimation.

Why are Story Points better than Hours?

With man-hours, developers expect that they’ll log the exact number of hours estimated for the sprint. But that’s a double-edged sword. If they exceed the number of hours estimated for a sprint, then it suggests they’re a poor performer. But if they complete the sprint under the estimated number of hours, then it means that there was something wrong with the estimate.

Story Points offer four main advantages over man-hours:

1. No correlation with skills and experience of the estimator

As we already mentioned, a specialist who estimates a task isn’t always the one who implements it. Senior and Junior developers need different amounts of time to complete the same task. The only way to avoid all this is to make a developer who estimates a project also implements that project.

Story Points eliminate this problem, because they are a universal measurement across the whole team. The estimate doesn’t depend on who’s implementing the story. All team members, with different skill levels, can discuss it together and come to a single conclusion.

The whole team can get a clear understanding of the story size and complexity. This is the main advantage of story points.

2. Velocity is Tracked

Another key to the power of Story Points estimation is velocity. Velocity is a powerful capacity planning method that demonstrates how much product backlog effort a software development team can successfully handle in one sprint. The goal of a team is to raise its velocity.

Team members discuss ways to achieve greater velocity during retrospectives after each sprint. The higher the team's velocity, the higher the team's capacity to perform a given task quicker and more efficiently.

But velocity is a relative value that can change during the course of the project. And here, we find the next advantage – you will not need to re-estimate your project if velocity changes, whereas estimating in man-hours would require you to perform a recalculation.

3. No Re-Estimation if Velocity Changes (Flexibility)

Another value of Story Points is that they let you re-plan product release deadlines without re-estimating all tasks if members of the team are changed.

It often happens that one person estimates a project, but other people complete the tasks. In this case, Story Points are indispensable.

Let’s consider several examples.

Example 1

Our company has a project at 200 SP. One developer starts working on it. His velocity is 1 SP per 3 hours. The start date is May 30th. Based on this information, it’s easy to calculate the project release date.

1. The time needed to finish all the work:

where Qsp is the general quantity of SP in the project and t is the time to complete 1 SP.

200x3 = 600 (hours).

2. The number of workdays:

where Nw is number of workdays, T is the time needed to finish all the work, and Prt is the quantity of productive hours in the working day (usually 6 hours)

600 / 6 = 100 (workdays).

Having a calendar at hand, we can then calculate a release date — October 14th.

If for some reasons we change the developer and the new developer works with the velocity of 1 SP per 1.5 hours, then we can quickly re-calculate our date. Now the number of workdays required is 50 and our date of release will be August 5th.

Example 2

Our project should be completed for 200 SP. The team fulfills 40 SP during one sprint. We know that 1 sprint is equal to 2 weeks.The start date is May 30th. Let’s calculate:

where T is the general time for completion of the whole project, Ns is the number of sprints in the project, and t is the time needed for one sprint.

(200/40)*2 = 10 (weeks).

The release date is August 8th.

But let’s say that some changes have occurred, and the velocity of the team has changed. Now the team completes 50 SP during one sprint. It will be easy to re-calculate our date.

(200/50)*2 = 8 (weeks).

The release date is now July 25th. Thus, Story Points allow our Product Owner to see more precise release dates after any changes in the team.

You see that we can convert abstract Story Points into more understandable days without any problems. We monitor the whole development process, and can change it at any stage if it is necessary.

4. Perfect for high-level estimation

Story Points is an indispensable technique for performing an initial estimation. Whereas it’s almost impossible to estimate a User Story in hours without the defined data model and precise requirements, Story Points help you understand the scope of work, at least on a high level. 

When making estimates, Story Points also help you account for plenty of dependencies such as third-party integrations. Thus, if you plan to implement an API integration, but you don’t have access to the API documentation, Story Points estimation is the most reasonable approach to opt for, because they allow the team to account for any uncertainty related to the work item being estimated. 

Let’s see an example.

Example 3

Suppose you have a User Story for your marketplace startup, and it involves integration with a third-party inventory management system.

Before you buy a subscription plan for the API, it's hard to say how many hours precisely the User Story will take since you don't have access to the API documentation and don’t know the precise scope of the integration - number of endpoints, webhooks, and background jobs to implement. 

Imagine that the total work scope is 200 Story Points, and you estimate that User Story with 5 Story Points, assuming that you've considered all the risks and difficulties. However, after you gain access to the documentation, you find out that the task is more complicated, so you need to reestimate the User Story to 8 Story Points. 

Now it's easy to recalculate the release date if needed.

Let’s sum up

Story Points have acquired a reputation as a stable index that’s independent of the skill or experience of team members, lets you track a team’s velocity, and helps you stay flexible in re-planning project release dates.

Recently, some specialists have begun using a combination of both Story Points and man-hours. But still, on the basis of our own experience, we are confident that Story Points offer the greatest utility for high-level planning.