by Shanil Wiratunga,

Business Analysis (BAPL) Consultant

Many moons ago as a young techy I spent numerous hours and days with my teammates, working in laborious estimation sessions, trying to arrive at the most accurate estimate to develop features of a Software solution. From here we created Gantt charts and plans so detailed and lengthy, that they ended up looking like bowls of noodles. It didn’t stop there, as scope and requirement changes would creep in, we’d have to rework these estimates, and the lengthy, stripy charts all over again. But did this help to deliver our projects on time? Well the answer to that question is quite complicated. Yes, we delivered on time, but that is after having toiled away many weekends, public holidays and after office hours to ensure all the remaining work was squeezed in.

This pain staking process went on for many years to come until one day I had the opportunity to attend a seminar on Agile. That was my very first sneak peek at this wonderful world. I learnt many concepts, techniques, theories and most importantly a different way of estimating called ‘Relative Estimation’. I started my quest to learn more about this technique as much as I did on the other Agile concepts. The more I learnt through research and experience, the more I realised how simple, yet effective relative estimation is. It is something we always do. It second nature to us, and hence, the reason why it works so well too.

Before we delve deeper into this, let’s have a look at what estimation in is in the first place. Why it is so challenging?  If then, what is relative estimation? Why I think relative estimation is a more conducive and simple way of estimating in software development projects, as opposed to the conventional absolute estimation.

What Is estimation or absolute estimation?

In Software development projects estimation is used for predicting the most realistic amount of effort required to develop or maintain software, based on incomplete, uncertain, and clouded inputs. One of the key attributes that is predicted in the process of estimation is the time to pursue a course of action. From this teams estimate the cost associated to the time and the value associated with the suggested course of action.

There are many methods that are used for estimation as well. Some of them are:

• Top down
• Bottom up
• Rough Order of Magnitude (ROM)
• Rolling wave
• Delphi
• PERT

Why is absolute estimating so challenging?

Firstly, it must be said that we humans were not designed for absolute estimations. Our brain alone does not have the capability of doing absolute measurements and estimates. We tend to be optimistic or pessimistic more than realistic most of the time. However, it’s easier for humans to relate to similar items than to guess the actual size of things. Humans are designed to look at things comparatively, and relatively.

Secondly, in a world of rapidly changing technology, requirements and scope changes are inevitable. There are so many unknowns and moving parts in a typical project, which makes estimating with an acceptable level of accuracy a nightmare.

What is relative estimation?

Relative estimation is the process of estimating items, not by units of time or size separately, but rather by comparing how they are similar to each other in terms of complexity.  Agile alliance defines relative estimation as one of the several distinct flavours of estimation used in Agile teams, and consists of estimating tasks or user stories, not separately and in absolute units of time, but by comparison or by grouping of items of equivalent difficulty. Basically, relative estimation applies the principle that comparing is much quicker and more accurate than absolute estimation.

Let’s look at an example from what we do almost every day. Buying coffee.  When we go to a coffee shop to get a coffee the Barista asks us to choose the size of the coffee. Assuming we have never been to the coffee shop before we would not know the sizes of the cups, as large, medium or small. Either we could make a lucky guess thinking large would be too large or a small would be too small and settle for the medium, or we could look at the coffee cups kept on the coffee machine to determine the size required, thinking of the sizes of cups we have had in the past. It is very unlikely that we would think in absolute terms whether the small cup is 40 ml or 50 ml or the large is 100 ml before a decision is made. So, what have we done here? We have looked at the relative sizes of the coffee cups and made a relative estimate, to predict what might satisfy our coffee cravings for that moment in time.

Now let’s bake some cakes with relative estimation. Suppose you as a participant is required to bake 3 cakes for a Master Chef competition. The types of cakes to be baked are given by the judges, with 3 sample cakes already made in front of you. The three cakes are of three different sizes. You are supposed to make the 3 cakes exactly the same way as the sample cakes including the same dimensions, colours, flavours etc.  The judges say that there is however one condition that you need to be aware of. That is, you need to let them know how long it would take to bake the 3 cakes beforehand, and you need to stick to the time you commit to. The estimated time frame given would be validated by the expert judges, to ascertain if it’s realistic or too blown up.

So how can you do this? In the past you have made one of the cakes, which is the smallest out of the three, therefore you know how long it would take to make it.  Let say it’s one hour. That could be considered the length of the sprint. You have no idea how to make the other 2 cakes, and how long it would take, the ingredients required etc. But, can assume that the medium sized cake is three times the size of the small one, and the largest is about 5 times the size of the small one. Let’s classify these cakes using a unit of measurement called ‘Cake points’ looking at their relative sizes. The smallest cake could be given 10 cake points. Therefore, the medium sized cake could be given 30 cake points and the large cake 50 cake points. These numbers are just arbitrary numbers, and do not relate to a specific unit of size or time. Since it was said that the smallest cake i.e. 10 Cake points cake can be made in one hour which is the sprint duration, we could easily say that the velocity is 10 Cake points per Sprint. So what’s the total amount of work required for all 3 cakes looking at their relative sizes? It would be 10+30+50=90 Cake points. Given the velocity as 10 Cake points, a little bit of math can show you that you will need 9 sprints to make all 3 cakes. With one sprint being an hour’s duration, it could be determined that all these cakes would take 9 hours to make.   This is the essence of relative estimation. This theory can be applied to Software development projects as well. You could look at a feature and say “I think the feature A is twice as complex as feature B“, with the given knowledge by completing feature A in the past. There is no mention of time requirement, just that it is more complex than the other. Therefore, if feature A took 3 weeks to complete, it is reasonable to think that feature B would take 6 weeks. Isn’t that simple.

Estimation, whether relative or absolute, can be very challenging especially in the world of software development. Even though no estimation technique may be perfect, by comparison relative estimation is a simple, effective and ‘relatively’ accurate method of estimation.

To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn