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

  • 80883 views
  • 5 minutes

Anastasiya V.

Project Manager

Viktoria K.

Copywriter

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:

Nw=T/Prt,
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.

Authors:

Anastasiya V.

Project Manager

Viktoria K.

Copywriter

Share article with

Comments (6)
to leave a comment
Will D. Robinson 4 months ago
This sounds great. Where I'm struggling is with how you know whether you can afford the project up front? How do you convert it to a Price if you don't know how long it's going to take? Your analogy doesn't seem to be a fit for consulting work where you get paid to build something for a price you agree to in advance. If you bring a new person on the project who is half as productive, who is going to pay for the doubling of the schedule and doubling of the price? No customer I know. I do agree with all your reasons why estimating is hard. I just don't see how story points solve them if you are not committing. Maybe this works for internal projects and product development where you don't measure costs.
Reply
Viсtoria S. 4 months ago Will D. Robinson
Hi! For the rough estimate, we use hours because there is no data to transform the story points into time. Then, we need to know how much time it takes to complete 1 story point. Speaking of bringing a new person to the project, we always try to find a person who has a corresponding professional level to avoid “doubling of the schedule”.
Zachary Kniebel 4 months ago
Considering this is one of the first results on Google, I feel obliged to point out that your formula T=Qsp*t is incomplete, as you haven't pointed out that the value t must be calculated based on team point velocity over time. Story points are a proxy for hours and the relationship between story points and hours is exponential - not direct, as is implied by this formula, as-is. Story points are meant to represent complexity rather than hours. The assumption is that a larger task with more dependencies has more opportunity for things to go wrong and this "risk" or "complexity" must be accounted for. To relate to real-world scenarios, story points are meant to provide a quantifiable measurement for effort for a task in which a resource may say "well, it could take 3 hours or it could take 3 days if x happens." For this reason, as the number of story points increase, the number of (roughly) equivalent hours must increase at a greater rate. For example, 1 story point may be equal to 1 hour, 2 story points to 4 hours, 3 story points to a day, 5 story points to 1 week, and 8 story points to two weeks. In the end, when you graph your story points (x) vs hours (y) you should always get an exponential relationship (curve). With that being said, business people don't want to see a curve and neither do project managers who want an idea of how a project is progressing. As such, an average can be used to determine the *average value of 1 story point in hours* (this is what your t value should represent). Because story point values are generally chosen from fibonacci numbers (or an alternative system) with a pre-determined maximum (often 8 or 13) the margin of error on this average is limited, however it is recommended that this average be reviewed at the end of each sprint. Doing so may also help to identify unanticipated project issues and slowdowns.
Reply
Nikhil Chhabra 6 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.
Reply
Zachary Kniebel 4 months 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.
Viсtoria S. 6 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!

Share