Story Points vs. Hours: What Makes Story Points WinTeams are actively doing estimations in story points owing to the advantages it offers over hours-based estimates. Find out more in this comprehensive guide.
Estimation is one of the important elements in the planning process of any agile project. When estimations are done rightly, it helps the product owners and the product team to prioritize things rightly, maximize their efficiency, and ensure quality deliveries. However, when it comes to how to do estimates, the first approach that comes to mind is time-based estimates.
Traditionally, project planning is associated with how many days it would take to complete it. So, project teams, managers, and other associated personnel try their best to set accurate time-based estimates. They spend significant time to find out how much time (hours, days, or weeks) they need to complete the project/task without delays. Although hours-based estimates can serve the job, there are other methods too that can be used for estimations. One such method is story points estimates. Estimation in story points is used by agile teams to do estimates based on the efforts required to complete the task, not the time it needs.
Now the main question is which estimation technique is the best one? Either a team should pick story points or go for traditional hours-based estimates? Well, there is a non-stop debate on this topic, and you will find supporters for both types of estimation methods. In this article, we will present a comprehensive comparison of both of them with their advantages and disadvantages. In the end, we will present our narrative about why we think story points estimation is a technique you should pick.
Story points are a unit of measure that present the relative estimate of the efforts required from the team to deliver a story. A story can be any nature of work/item, such as software development, UI/UX design, analysis, testing, and similar others. Similarly, a team can include all contributors, such as developers, designers, analysts, testers, product owners, etc.
When a team estimates with story points, members give a point value to all items. But the raw values that members give are not that important compared to the relative values. For example, if a story is given a value of "2", then it would mean that it is twice the size/complexity compared to the story with the value of "1". However, the team can also give values like 10, 20, or 30, instead of 1, 2, or 3. In short, it is the relative values that are important not the raw values assigned by members.
Since story points reflect the efforts required by the team to complete the story, the estimate should involve all the elements that can influence the team's ability to complete the story. The main elements in this perspective are:
- The amount of work.
- The complexity of work.
- Uncertainties and risks in the work.
When a team considers the above three elements during estimation with story points, then it is in a better position to have more accurate estimates. Now let's discuss how story points estimation actually works.
Story points estimation can be better understood if the process is divided into multiple steps. So, the following are the 5 main steps involved in the process of story point estimation:
The team should finalize what type of numeric scale it wants to use to give points to the items planned for estimation. They can simply pick the linear scale (1, 2, 3, 4, 5, 6, 7, and so on) or the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, and so on). However, it is recommended to pick the Fibonacci sequence or any other numeric scale that has a significant gap between numbers so that the team could distinguish the efforts required to complete different items. That's the reason you will also see teams using the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, and 100).
Once the numeric scale is finalized, the next step is to finalize what you want to achieve, such as new features release, new software development, etc. It is preferred to format project tasks or backlog items as user stories. Use stories are basically descriptions of project tasks from the viewpoint of end-users, such as what needs they want to fulfill, what are their expectations, etc. So, when a team writes a user story, it can understand more about user expectations and intentions, thereby making estimates more accurate and fruitful.
For accurate estimates, it is also important to find reference points or historical data that can help the team to compare data and make better estimates. So, if you have performed a similar estimate in the past, then analyze its outcomes to understand how things went at that time.
In order to make a better guess of the efforts required to complete estimation items, the team must also be clear about the size of the items, the complexity of the items, and risks or uncertainties associated with the items. The size reflects the number of tasks required to complete the user story, while the complexity reflects the difficulty value of the story and the skills level of the team in it. Similarly, the risks and uncertainties reflect the possible delays or other complications that can arise during any stage.
When the team has completed all the above steps, it is ready to discuss user stories and set estimates. It is important that team members give unbiased estimates. Therefore, estimation techniques such as Planning Poker, Async Poker, T-Shirt Sizing, and similar other techniques are used by them to ensure unbiased estimates. Planning Poker is one of the most popular estimation techniques used by teams. Here is a quick overview of how a Planning Poker session proceeds:
- Team members join the session where they are briefed about the user story.
- They discuss the story further to clear their doubts.
- Once all doubts are answered, every member gives a value that he/she believes best suits the effort required to complete the user story. Mostly, members are given poker-style playing cards having modified Fibonacci sequence values. So, everyone chooses the card and then they all display simultaneously.
- If everyone has given the same value, then that's the team's final estimate. In case of a major deviation in values, then the team conducts more discussion to reach a consensus.
This way, a team can use story points estimation to estimate the efforts required to complete the items without involving the strict timeframe or biased human opinions. However, once the final estimate is agreed upon, the team can even use it to guess the release date (if required).
Following are the major pros and cons of estimating in story points:
- It involves multiple developers and other personnel in the estimation process, so the discussion has more depth, thereby resulting in more accurate estimates.
- Each member gives the estimate based on his/her understanding, and then the combined team estimate is finalized. This encourages a collaborative environment with unbiased estimates.
- The product team becomes more flexible in changing development time. So, when they encounter issues that can delay the progress, they have room to adjust the delivery time.
- The team can track its velocity as it proceeds with the project. This way, they can give a more precise launch date.
- Past estimates act as a reference resource for future similar estimates, thereby reducing the time to estimate while ensuring more realistic estimates.
- It is a time-consuming process and also requires skills and experience to do accurate estimates.
- It requires a diverse team to do estimates.
- It makes project budgeting complex.
- New teams can struggle to do accurate estimates, at least in the first 2-3 sprints.
Following are the major pros and cons of estimating in hours:
- It is a traditional and familiar way of doing estimates. Product teams, stakeholders, product owners, customers, and all other individuals are familiar with time-based estimation.
- It does not require any prior training or specific software to do estimates. It is an easy and straightforward process.
- Since clients mostly pay in hours, so giving them estimates in hours is much better for budgeting. Moreover, if the client's preference is more on budget rather than launch date, then again hours-based estimates are effective.
- It does not require a large team to do a comprehensive discussion on user stories and make estimates. Even a single or few developers can sit and set the deadlines.
- Projects often involve risks and uncertainties, which can occur at any instant. So, when a team is working with fixed commitment, those uncertainties can increase the pressure and might compromise productivity and product quality.
- If the project size is big, then it is hard to estimate it in hours. Similarly, if developers don't have much experience on that project, then again estimates in hours can be highly inefficient.
- When a developer does estimate alone, then there are chances of involvement of emotional or over-confident attributes, which can result in either overestimation or underestimation.
- A team doesn't get the flexibility in its commitment. So, the focus might shift to timely deliveries instead of quality deliveries.
The above pros and cons of estimating in story points and hours are self-explaining the key areas where story points dominate hours-based estimates. For better understanding, the below points briefs the main advantages teams can get with estimating in story points compared to hours:
Story points estimates encourage a culture of collaboration where both the ones going to work on the project and others can contribute their knowledge to pinpoint hidden challenges and do accurate estimates. Moreover, if developers get changed during the sprint session, then it won't influence the estimate because it is an average collaborative estimate, not an individual or small group estimate as in the case of hours-based estimates.
As narrated above, it becomes difficult to do time-based estimates when the project is complex or involves dependencies. So, if a team does an hours-based estimate of such a project, then it can cause a troublesome situation later on. However, story points estimate involves a proper discussion session in which experienced personnel evaluates all the ins and outs of the project before reaching a combined team's final estimate. This makes estimates of complex projects more simplified.
Hours-based estimates make a team bound to specific deadlines. So, project complexities, more features demand, resources limitations, skills gaps, and similar other factors become severe concerning issues for the team. On the other hand, story points estimates give the team flexibility to re-plan delivery time without much of a hassle.
A velocity is a measure to track the amount of work completed by the team in one sprint. A higher velocity indicates that a team can do more progress with high efficiency. It is easy to measure velocity with story points, as they both are relative values and there is no need to re-estimating the project when there is a change in velocity. However, when efforts are calculated based on hours worked, then the team has to recalculate the velocity because of the non-relative nature of hours.
In a nutshell, story points estimation empowers teams to have better determination about the efforts required to complete the project. This way, teams can prioritize and organize processes more efficiently without struggling to meet tough deadlines. However, estimation in story points also requires experience to ensure accurate estimates. New teams might make mistakes during the initial few estimates, but the gradual experience will let them have more trustworthy estimates.