All you need in this life is ignorance and confidence, and then success is sure.
— Mark Twain
We have probably all heard the endless debate about whether the estimation of development work should be done in story points or in hours. Some people even get inventive and translate hours into story points, though self-defined conversion scales say, “1 story point = 6–8 hours.”
Although this approach might seem intuitive, and simple enough, it can defeat the purpose of relative estimation and even introduce an extra layer of complexity into the system.
Story points or hours — or both?
Let’s try to understand the estimation methods by taking an example of two user stories, A and B, with Story B requiring approximately double the effort to implement than Story A. Now let’s have a look at the scenarios that might unfold.
Scenario 1: Estimation in story points
The team estimates stories in story points, and all members of the team agree that Story B will take double the effort in completion than that of Story A. This will be true for each member of the team in terms of efforts required. So Story A is assigned 1 story point and story B is assigned 2 story points. In this case of relative estimation, the whole team is on the same page with regard to understanding the nature of work.
Scenario 2: Estimation in hours
The team estimates stories in hours. There is a variability in perception attributable to past experience and the capability of developers. Developer X believes he implemented stories like Story A in 3 hours and thus gives an estimate of 6 hours for Story B. Developer Y, who is relatively new to the team, believes he implemented stories like Story A in 6 hours and thus gives an estimate of 12 hours for Story B. We can see the dysfunction in developing a common understanding of the work — it makes the estimation dependent on a particular person on the team.
Scenario 3: Estimation based on hour-to-story points conversion
The team estimates stories in hours, as in scenario 2, and then converts them into story points by using this formula: 1 story point = 3 hours. Here are the estimates of user stories according to Developers X and Y:
||Estimate for Story A
||Estimate for Story B
We can see that the above estimates do not help either Developer X or Y. It also becomes really complicated to develop a common understanding across the team regarding the work, as the result of the extra layer of complexity added by hour-to-story point conversion. Team members will keep doing the mental math of converting hours to story points during estimation, which will obviate the inherent benefit of simplification in relative estimation.
What’s the best estimation method?
Analyzing all three possible scenarios that can occur for Agile teams while estimation, we can see that Scenario 1 offers the following benefits:
- It eliminates the need for reestimation, because it works as a size-based estimate, and it also accounts for the learning curve. So once the team matures, we might have to change the hour-based estimates. However, the same change will not be needed with relative estimation in story points.
- Story point estimation tends to be faster and can be managed better in a timebox. The team will have more time to contribute in other value-adding activities.
- Because there is a single estimate in terms of story points, it helps break the functional barriers inside the team and promote cross-functional collaboration.
- Relative estimation also curbs the apprehensions associated with commitment. The team is usually less stressed while estimating in story points, whereas estimation in days introduces uncertainty.
- Story points paint a better picture of team performance as a whole in terms of velocity. This velocity data can, in turn, be used in release planning.
Although which estimation technique works best will remain open for debate, I maintain that pegging story points to hours, and the subsequent conversion, introduces needless complexity and loses one of the main benefits of simplicity engrained in story point estimation.