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

  • 1 comment

Anastasiya V.

Project Manager

Viktoria K.


In our previous article about Story Points estimation, we concluded that Story Points are a handy and efficient measurement technique for estimating the amount of effort a team needs to develop a particular feature. Now, we’d like to talk about why, here at RubyGarage, we prefer estimating in Agile Story Points to hours.

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

story points estimating

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.

Why Story Points are 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 three 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.

Estimate with Story Points

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.

Story points vs hours

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:

T = Qsp*t,
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:

T = Ns*t,
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.

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.

Share article with

Comments (2)
to leave a comment
Nikhil Chhabra about 2 months ago
1: How is story not just another word for 'hour'. Because at the end you said 1 SP equals some time t. 2: People can argue about hours, people can argue about story points. Both the things depends on the person. 3: Highly skilled person might find the task less complex. And person with lower skill will find the same task more complex. So we face the same problem. 4: If discussion among ourselves could solve the problem than we could come to a conclusion even while estimating with hours.
Zachary Kniebel 6 days ago Nikhil Chhabra
Victoria is absolutely correct. Just to elaborate a little bit, because different resources at different skill levels may find a task more or less complex than other resources, the complexity of the task should be based on the type of work involved, dependencies and unknowns, amount of time and type of testing required, etc. It is important to remember that story points provide a quantifiable way of accurately measuring activities for which one might say "this could take 3 hours or it could take 3 days if x happens", and incorporating that into their project planning. Generally speaking, all known User Stories (assuming agile, you may not know all User Stories up front, but you may know Features and should size features - you should not size Epics) for the project should be sized in story points up front (and reviewed and resized as needed throughout the project; newly identified User Stories should be sized as well). This will enable you to use points to project progress and completion dates at the macro (project) level. For the micro (sprint/iteration/milestone) level, each User Story should consist of "tasks" describing a single unit of work that must be completed in order to make progress on the User Story. Individual "tasks" should not be sized in story points, but rather estimated using hours. This estimation effort is usually performed by the whole team during or in advance of (by the leads and then reviewed and modified during by whole team) the sprint/iteration/milestone planning meeting. During that meeting, the task should also be assigned to a resource who should have the opportunity to request that the estimate be changed based on individual skill level, familiarity with the technology, etc. The estimate should not change after that point. Hours estimates are effective for gauging progress and performance at a micro-scale, but they break down rapidly at scale. In practical scenarios hours estimates are never accurate when used to track progress on a multi-sprint/iteration/milestone project, and are only achievable from a planning perspective if very heavily padded for contingency. Story points, on the other hand, have contingency built in, as they measure complexity and can be, at a macro-scale, averaged out to the amount of effort in units of complexity that can be completed in a given unit of time by the project team, thus accommodating all skill levels, risks, dependencies, etc. For example, if the team completes 18 points in the third sprint, 22 in the fourth and 20 in the fifth then it can be said that the team completes an average of 20 points per sprint, and thus has a velocity of 20 points. Assuming that each sprint is 2 weeks long, each sprint is 80 hours and thus each story point is roughly equivalent to 80 / 20 = 4 hours for project planning. This value is not to be used by the team for sizing, but rather is for project planning purposes only. The team should continue to use their existing sizing specification (e.g. 1 point roughly equals 1 hour, 2 points roughly equals 4 hours, 3 points roughly equals 2 days, etc.), rather than this average.
Your comment will appear after the admin moderation
Viсtoria S. about 2 months ago Nikhil Chhabra
Hi! When we estimate with Story Points, we consider the complexity of a task. So, one SP doesn’t equal a particular amount of time because different people can spend a different amount of time completing the same task. You’re right that a more skilled person might find the task less complex. That’s why the team discusses tasks to come to a single conclusion. We’d like to note that using Story Points for project estimation is one of the different approaches that have both pros and cons. We prefer using Story Points because this approach offers more flexibility. Thus, if a velocity changes, we don’t need to re-estimate a project.

Subscribe via email and know it all first!