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:
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:
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:
Following are the major pros and cons of estimating in hours:
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.
