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