Story Point vs Hours

Man-Hours

Estimating in man-hours is one of the most widespread approaches for measuring teamwork. 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 the drawbacks of estimating in man-hours outweigh the advantages. 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 Point

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 a 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 are no User Stories to compare with, a team needs to identify a Base Story and create a Matrix for Estimation.

Story Points advantages over man-hours

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.

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.

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 helps 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.