Why use relative estimates?

We use estimation every day, i.e. we estimate how much the bill will be, we estimate how long time it takes to drive to our destination, we ask for estimation when we ask a craftsman to do something for us both in time and money etc. etc. This estimation is mostly using absolute estimation.

When it comes to estimation in IT projects, we use either absolute estimation or relative estimation.

People working with waterfall projects are used to estimate effort in time, i.e. absolute estimation. When we estimate stories in Agile, we recommend to use relative estimates. There are several reasons to this:

• Comparing is faster than analyzing.
• Comparing is usually more accurate than analyzing.
• Comparing does not have the “accurate” feeling.

relative estimation all the time, i.e. if someone asked how big (m2) Europe is compared to Australia you would most likely compare the maps.

Instead of trying to break down a requirement into smaller tasks (and estimating these tasks), teams compare the relative effort of completing a new requirement to the relative effort of a previously estimated requirement.

When using relative estimates, the team will get what we call a velocity. A team’s velocity is a measure of how much work they can do in a sprint.

Velocity is important to the team! It shows the team if they improve (over time) and it can be used to estimate when a given set of stories on the backlog can be implemented and delivered to the customer.

If the team use relative story points, they will see a change in velocity over time, i.e. most teams will see that their velocity goes up, unless they accumulate technical debt or do not have automatic tests, in that case it will most likely go down.

If the team uses absolute time estimates for stories, they will always deliver the same amount of work in hours, i.e. if they have 2 week sprints, 5 people, each working 30h/week on the sprint backlog, they will deliver 300h. If they estimate stories in days or hours, they will not see the improvements the team do, as they will have a fixed velocity, they may be able to make good prediction of when they will deliver, but they will not have an easy way to see if they improve or not.

Estimates with absolute reference

When you use relative estimation, you will see a difference over time in how the team perform, let’s assume that they become double as fast at delivering, the velocity will then become double, example: Before they were able to deliver 5 stories worth 8 points, now they can deliver 10 stories worth 8 points

And a little reminder — Estimation is always guessing when it comes to complex SW, so creating more “correct” estimates is just an illusion.

I hope this could inspire you to use relative estimates — please share your own experience!

In the next blog, I will show how to create a reference story which is needed to do relative estimation!

Best regards

Rune Hvalsøe

Agile Coach, Deloitte consulting group

SAFe Gold partner