There are several estimation techniques when it comes to project management and agile development. These normally depend on the metric being estimated, which can either be time, money, or even the effort required in the project at hand. In this particular article, we will focus on two common metrics-story hours and hours.
We will delve deeper into what these are before giving you a detailed comparison. Part of the article will also propose the best out of the two, complete with supporting reasons. We hope that you will have picked your preferred one by the end of our article. Let’s get started.
Story Points
A story point is a metric used in agile to establish the difficulty of implementing a specific user story. This is an abstract measure of the effort that a team requires to implement the user story. It, therefore, informs the team members on the difficulty level of a given story.
Several things bring about these difficulties. However, the most common ons are the complexities, risks, and efforts involved. This brings us to story point estimation, a relative estimation technique conducted at the product backlog grooming sessions.
During story point estimation, the team responsible for development and testing evaluates the product backlog. They estimate the product backlog grooming before sprint planning occurs to ensure that the process is highly efficient.
During this estimation, the agile team considers if the sprint plan can be conducted efficiently, whether the user story has been split reasonably and if there is adequate information for efficient completion.
However, note that these teams usually use the Fibonacci sequence when estimating story points and not the usual assessment methods.
Performing Agile Estimation Using Story Points
Each team involved in the process must find the baseline story. Keep in mind that this does not have to be the smallest figure but the most reasonable one. Afterward, all the user stories should be sized by comparing them with the baseline.
The process that follows is pretty simple. All you have to is to find out whether a story will take longer than a given reference story or if it will be lesser than another reference story. If you have enough reference stories, you will have an easy time finding a similar-sized story to award points based on a given factor.
Remember, during story point estimations, a point value is often given to every story. Relative values normally play an essential point over the raw values. This means that a story with two story points is normally twice as much as that with only one point.
However, when the single-story point exceeds 21. The user story must be split again.
Advantages of Using Story Points
- It ensures that the entire team is responsible for the estimation making it more trustworthy.
- It helps the teams realize how difficult each task is for adequate preparation.
- It does away with time ticking, which can b pretty stressful.
- It does not focus on the time needed to perform the task, thus removing too much pressure.
- Th task is usually given an estimate that is independent from the developer expected to implement it. This, therefore, makes it a one for all and all for all approach to task estimation.
Disadvantages of Using Story Points
- It is not a very transparent means of task estimation.
- It needs two or three sprints to master story points, estimate and predict the development team’s capacity.
Hours
This is another preferred approach used to measure the time that a given task is expected to take and come up with deadlines. This brings us to hours estimation, which focuses on the amount of work that one can do within a record of one hour.
Just like in story point estimations, there are several things to consider for hour estimates. First, you need to ask yourself whether the involved developer is a full-time or part-time participant. You must also consider the amount of time that the sprint will take and the types and quantity of sprint ceremonies in the project calendar.
Also, consider whether the developer attends other meetings that are not part of the project and if he/ she has planned a holiday or day-offs for the next sprint. Lastly, find out whether you should include some time for hotfixes.
The value obtained from the hourly estimation can be used to tell the expected deadline of the project.
Advantages of Using Hours
Using the person-hours to estimate the amount of work that a team can do comes with its fair share of advantages. These are:
- It makes time estimation of small tasks easier, especially when they know how much time they need.
- It allows a team to estimate sprint by the hours capacity, thus removing the need to consider the team velocity.
Disadvantages of Using Hours
- It is usually the responsibility of one person.
- Bigger tasks may be underestimated or overestimated.
- Estimations based on time only reflect the capability of the developer who came up with them.
- Most tasks are not usually done before the said limits.
- If the task is not completed within the given estimated time, there will be stress that may impair performance.
One thing that stands out from this discussion is that the cons of hours outweigh the pros. We will se how this affects our verdict at the end of the article. For now, let us compare these two.
Comparison Between Story Points and Hours
Story points are usually different from hours. Even though these two metrics are used for estimations, they have different characteristics that set them worlds apart. Based on these, we will discover the best metric to use before commencing a task.
- Time estimates are normally done by the developers and do not require team members’ effort. It is done by one individual who is then mandated with the implementation of the given sprint. However, story point estimates involve the input of the entire team, who get to know just how complex the project is. It, therefore, removes the burden of individual estimation, which brings with it its fair share of shortcomings.
- Time estimation (through hours) means that you can estimate sprint by the hour’s capacity, thus eliminating the need to investigate the team velocity. However, you may still need to teach your team how to estimate the velocity, just that it is not necessary for person-hour estimation. On the other hand, story point estimation tracks velocity, which is the quantity of product backlog effort that a software development team can easily handle in a sprint. It plays an essential role in agile since teams must always strive to raise this value.
- A change in velocity in person-hours estimation forces you to conduct a recalculation, which you do not need for story points estimation. With story points, you get the liberty to extend your product release deadlines without performing a re-estimation of the tasks. On the other hand, man-hour estimation does not offer you this flexibility since the person who does the estimation is mandated with implementing the given task. Therefore, if anything changes, he/she will have to reestimate and come up with new deadlines.
- Story points estimation uses Fibonacci-like formula such as 1, 2, 3, 5, whereas, for hours, you can use time such as 12h or even days. Th Fibonacci sequence used in story points helps drive quick estimations since it presents discrete choices which a team must make. Proponents of story points argue that the use of points rather than hours is essential in making better judgments and can therefore help the team achieve higher levels of accuracy as compared to total hours estimation.
- Story points uses relative estimations, whereas hour estimations only depend on raw values. Relative estimations normally compare something to a given reference.
Which One Is Better?
Most companies still estimate tasks by the hours needed, given that it is a widespread approach. However, from our discussion, it is evident that it does not match story points. For hours, the developers are expected to feed the exact hours estimated for every sprint. This either means that they are poor performers if they exceed this value, or the estimate was incorrect if the sprint is completed under the estimated time.
Story points, therefore, have major advantages over hours, making it a better metric of estimation. These are:
- It Tracks Velocity
This is perhaps one of the most outstanding advantages that story points bring to the table. Story point estimation tracks velocity, which is one of the most powerful capacity planning techniques. It shows the amount of product backlog effort that a software development team can handle in one sprint. The team should therefore ensure that they do everything possible to raise that value.
After each sprint, all the team members must discuss means of achieving even greater velocities. A team with a higher velocity can complete tasks more efficiently and quickly. However, not that this is a relative value that can easily change as the project progresses.
In case of any changes in team velocity, you do not have to reestimate your project, which is essential for hours estimation.
- It Is More Flexible
This is closely related to the last part of our first point. You do not need to conduct another estimation when the velocity changes when it comes to story points. These points allow you to replan the release deadlines of your products without having to reestimate all the tasks. This also applies if team members change as the project progresses.
- It Supports High-Level Estimation
One reason organizations are picking up the story points estimation technique is that it is perfect for high-level estimation. Story points come in handy when conducting an initial estimation. However, note that it may be impossible if you intend to estimate a user story in hours. You need a defined data model and several specific requirements. All in all, story points will still help you understand the scope of work at a higher level.
You can also account for several dependencies, such as third-party integrations, thanks to these points. They give you the level of flexibility you need, such as implementing an API integration without accessing the supporting documentation.
Your team will get to account for every uncertainty brought about by the work item underestimation.
- There Need to Be No Correlations with The Estimator’s Skills and Experience
Unlike in hourly estimations, the person who estimates a task is not necessarily expected to perform it. The story points estimation technique understands that senior and junior developers need different timeframes to complete the same tasks, and therefore, coming up with a harmonized value is absurd.
Story points, therefore, shifts the burden of estimation from an individual to the entire team. These are normally used as a common measurement across the whole team, meaning that the estimate does not rest on the person charged with implementing a story.
It ensures that all the team members, with their different skill levels, get to discuss and come up with on conclusion. Therefore, the entire team will understand the story size and its complexities, which makes it the main advantage.
However, note that these four points do not make story hours flawless. There are several things that you may have to look out for before deciding on either. Keep in mind that you cannot use story points to predict dates unless the velocity is known and previous data obtained.
Story points can also be pretty confusing and do not apply in all circumstances. It also presents the possibility of team members inflating story points to improve the team velocity. Lastly, teams can change, which may be a big blow to story points, given that it considers all team members’ capabilities.
Conclusion
We have exhausted some of the most important things that you should know regarding story points band hours. However, what stands out from our discussion is that the former is a better metric than the latter when it comes to task estimation. However, also take your time and go through the pro and con sections to decide what fits your organization.
