I posted this article on my more technical website www.codingepiphany.com a while ago. I thought this website is a more fitting home to this article. This article has been re-edited for better accuracy over the original.

One of the techniques that are commonly used within Agile Scrum methodology is the relative estimation. I often heard that relative estimation is not accurate or useless, therefore I take it upon myself to shed some light on what relative estimation really is.

Relative estimation is an estimation using relative numerical values, not dates. It could be Fibonacci numbers, modified Fibonacci collection (with a 2 in it) or any set of values you want to use. You can even use t-shirt size such as S/M/L, I’ll talk about how to use it on later articles.

The keyword that we have to pay attention is relative. That means the estimation is relative to something.

Stable Team

The relative estimation means that the estimations are relative to the scrum team itself. A complexity point of 8 as an example, can mean very different between one team to another. This can depend on the team’s experience, expertise, size or even something as simple as their interpretation of smaller complexity in terms of number.

This is why it’s ultimately important to have a stable cross-functional team in order to get the more accurate estimations. If any of the team members change then the meaning of the relative estimation points would change as well. Logically speaking this is simply because different team members have different abilities and different interpretations of complexity.

Team Velocity

Further to relative estimation is the ability to predict how many points the team can take within a time-boxed sprint. If the team is stable, then it’s possible to “calibrate” the total points predictions after about 3 sprints. Let’s say if on average the team can take 150 points, then there is a good chance that in the next iteration, the maximum number of points that the team can complete would be about 150 points. Again, let’s not forget this is an estimation, therefore there will be slippage to the total points estimation. These total points calculations are what we call the velocity.

In order to make velocity meaningful, the team has to be stable. Otherwise, a team with 150 points will not hit 150 points in the next iteration if the members are not the same.

A somehow closer example to this is the estimated range of your everyday cars. When everything in the car is stable, the engine, the fuel, the tyres, etc; you’ll get about the same range each time you fill out your tank in full. However, if you decided to change the exhaust or the fuel quality or even change the tuning of the engine, then next time you fill in the tank in full you’ll probably get different range than what the indicator estimates. You’ll only get more accurate estimations after a few full tanks (like your team sprints).

So, thinking about the car analogy, I’d like to re-iterate that the ability to estimate team total points and the ability to use previous velocity calculations as guidance are directly related to having a stable team.

Conclusion

In conclusion, relative estimation can be accurate if you use it correctly. Having stable team and understanding on how the team can use the story points are a must. It is also important that the team members take the estimation seriously as well.

At the minimum, these are the pre-requisites to get meaningful relative estimation and velocity:

• Stable team
• The ability of team members to take relative estimation seriously
• Consistent scoring metric. Don’t change from using Fibonacci into using sequential numbers halfway, that would render the calculations useless. You’ll need to re-calibrate over a few sprints again.

I will write more about sprint planning in my next articles. I hope that this article helps with understanding the meaning of relative estimation for agile scrum methodology.