Relative Estimation, is it a Gamble?

One of the techniques that is commonly used within Agile Scrum methodology is relative estimation. It is an often misunderstood estimation technique. Some say that it doesn’t make any sense, some say it is just a gamble and others say that it is useless. So, today I will try my best to shed some light on what relative estimation really is.

Relative estimation is done not using dates or days, in fact it’s using relative numerical value. It could be Fibonacci numbers, modified Fibonacci collection (with a 2 in it) or any set of values you want to use. Some people like to use t-shirt size such as S/M/L but I found it hard to calculate later on.

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

Stable Team

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, etc.

This is why it’s ultimately important to have a stable cross-functional team in order to get more accurate estimation. If any of the team members changed, be it developer or tester or any other team members, the meaning of the relative estimation points would change. 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 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 changed. It would be either more or less than 150; of course if you are lucky then you’ll get the same velocity somehow.

A somehow closer example to this is the estimated range of your every day 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, than 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.

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 stable team.

Conclusion

In conclusion, relative estimation is not a gamble if you use it correctly. Having stable team and understanding on how we the team can use the story points are a must. It is important that the team members take estimation sessions using story points seriously as well, otherwise we won’t be able to get the correct readings.

At 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

Failure to meet the necessary prerequisites above will reduce any form of relative estimation to a gamble.

I will write more about sprint planning in my next articles, hopefully the above helps on understand the meaning of relative estimation in agile scrum methodology.

Categorised in: Business Process