3 Reasons to Estimate with Story Points

In our previous article about estimating with Story Points, 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 Story Points as opposed to man-hours.

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 estimating 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?

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 implement that project.

Story Points eliminate this problem. Story Points 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 the estimate 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 Point 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 of estimating with Story Points – you will not need to re-estimate your project if velocity changes, whereas estimating in man-hours would require you to perform a recalculation.

Read rest of the article here