How to Get to Love Estimation by Doing Relative Estimation – or at Least the Value it Gives You

 

Estimation is something a lot of persons just strive to get around, as in not do at all. Or get someone else to do. But why? Estimation and relative estimation is one of the very powerful tools when it comes to bringing insight, if done the smart way. And by the way, there is more than one smart way.

How do you estimate

If you work in IT and have done so for some years, you either do estimations (often on someone else’s request) or you consistently try to shovel it to someone else. Or you belong to the group of people who have learned the power of estimation – and the value it brings to you.

But why should I estimate

There are many answers

• Some one else required you to do so. And they know the people processing your pay check, so don’t mess with them
• You are a manager and asking people to estimate so that you can forecast something. Unfortunately, sometimes you get to fill in the blanks yourself.
• You are on an agile team and do relative estimation in very short time, and apply these estimates for prediction of this and coming sprints outcome
• You are on an agile team and do not estimate at all! Despite this, you are still able to predict the outcome of this and coming sprints

For what are the estimates used

Generally speaking, the estimates are used to predict something either short term, or longer term. But honestly, when did you last see a long-term forecast based an estimate that hit bulls eye? It happens! But does the frequency match the cost of the estimations and updates to them? Also, when you factor in the misses?

How can we do it differently

In the agile ways of working you estimate often, but the time spend is quite limited. A planning session for a two-week iteration is around 2 hours, and you don’t estimate all of that time. Often you get to estimate 6-12 items during a planning session, and each estimation takes from 2-5 minutes. Nothing more. But that cannot be accurate? No, it isn’t. But that is no problem, because it all averages out (if you are really curious, there is some hairy math involved here).

The difference is to do relative estimation rather than absolute estimation. And provide the estimate in a timeless unit like Story Points, or whatever you prefer to call it. The estimates are subject to the team that did it, and can be used for their prediction, of eg how much they can deliver on an average iteration when used in combination with realised velocity for past iterations.

What are the benefits of relative estimation

It simple, fast, cost effective and meets the purpose of prediction to a reasonable extent. And furthermore, it activates the whole team in the estimation, leading to more qualified estimates. Last but not least, the estimation is coupled with Q&A, where more detailed information is transferred from requestor to the team. Information that was not pushed with the requirements, but instead pulled by the team.

Just before you let go of your whole estimation team, they are still useful when you place a bid in a competitive bidding.

Well are there any pitfalls of relative estimation

‘There is no such thing as a free lunch.’ Had there been one universal solution for every case, no one would notice as all other option would have vanished. So yes, conditions do apply. But they are actually fair. Only if you respect these, you can effectively use relative estimation for forecasting.

• The team who is going to deliver the work being estimated, are the ones to estimate (estimates are not transferable from team to team)
• The team – and everyone on the team – are doing the estimates. No manager or other is impacting the estimation. Again, the reason behind is that the team are the ones committing to it (not the manager)
• Access to information prior to, and in relation to the estimation from the source, that is the requestor of the work, is crucial. The team need to swift compare the case to other known cases to finalise the estimation.
• Respectful collaboration during the estimation. Whatever is brought up during the estimation, has been brought up for a reason. And this is both known issues that will increase the estimate and short cuts that will limit the estimates.
• The relative estimation is for operational purposes, can be applied for some tactical, but lost power way before the strategical domain.

How complicated is it to get started

The ‘how to’ can be explained in 2 minutes and a team can be operational doing this within an hour. So this is not really where you find the justification for not doing this. And as always, browse for videos or factor in an agile specialist to get you started. smooth and effective.

 

So all in all, I think this is a powerful tool a happily recommend. Low cost implementing, low cost running, and quite powerful predictive power also compared to traditional estimation.

 

So good luck getting started with relative estimation!

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting

 

PS: Not to estimate – often referred to as no estimate – is actually also to estimate. The reason is it implicitly assumes cases are of similar size and it therefore suffices to count the number of cases, rather than estimating them. This usually requires a quite mature team to implement.