Never again go against your nature when estimating
The human nature
Did you know that the humans are exceptionally great at some activities and incredibly bad at other(*Captian Obvious Flys Away* )? Yep yep, it’s true! Estimation, however, is one of the very few activities that we can be both very good and very bad at — depends on the way we approach it. Shockingly, in our day to day work, we are forced to use the wrong tools and mindset. It all stems from the human nature.
In this article, I will show you how to stop going against our nature and start using it to our advantage.
The problem — The humans are terrible at giving absolute estimates!
“How much time will this task take?”, “How long until the deal with this client is closed?”, “How many new users will this campaign bring us?” — these are all questions requiring an absolute answer — 3, 5, 1000. By design, the humans are very rarely equipped to answer these kinds of questions.
Let’s take software development for example — “How much time will this task take?”. In his book “Software Estimation: Demystifying the black art”, the author Steve McConnell has pointed out that, statistically, the estimations are normally between 4 times less or 4 times more than the actual time it took. Here is how the graphic looks:
Deal with it! If the developer tells you 3 months, be prepared to have it in a year. Let’s not take McConnell word for granted, though. Let’s test it ourselves. Here is a test for you. What’s the area in pixels of the blue square? Just give us a rough estimate. (Open the image in new tab to see it in full size.)
What is your guess? 2000px? 3000px? 6000px?
I surveyed my team and the answers varied from 400px to 16000px.
The answer is 16000px. How close were you? Not so close, eh? Don’t beat yourself up. Mother nature hasn’t built us to be good at these things. Occasionally someone might get lucky and get it right. Other times someone might have recently drawn a 400px by 400px square and see it familiar — therefore has expertise in blue square estimation. Don’t count on this happening too often.
As Ilan Goldstein , director at AxisAgile has stated in this article:
We humans are not naturally great estimators. We tend to either be optimists or pessimists and very rarely realists. I don’t even need to back this assertion up with statistics because I am confident that anyone reading this paragraph will agree!
Solution: Leverage the human nature in your favor
Compare!
Yep, this is the answer! We are amazing at… comparison! Which square from our test is bigger — blue or red? If I told you that the red square has area 4000px, would you easily estimate the area of the blue square? Probably. We almost effortlessly see that the red square fits four times in the blue one — hence 16000px. Way faster and way easier. Also much more accurate than your previous estimate, right? This is the case regardless of the estimation unit.
We are terrific at telling if something is bigger than another and very good at telling the magnitude of difference. This is what is called relative estimation!
How to implement it?
This is one of the main things that made Agile a far superior PM methodology than Waterfall.
The implementation of relative estimation is quite easy. Next time you want to estimate start with a task/feature you have historical data(how much time it took you to do it last time) and give it some relative time score. Then compare the next task to the known task and note how much bigger/smaller it is and assign a relative score too. Soon enough you will have a pool of tasks and their scores.
Note: If you, too, think bigger/smaller is ambiguous wait for the next section — Use Universal Scoring Formula
1.Use Story points — Jeff Sutherland, the creator of Scrum, has based the whole methodology on relative estimation. In scrum, you use Story Points — an imaginary estimation unit that is only used to compare pieces of work. You set a certain amount of points to your initial (reference task) and then compare on. Here is a more detailed explanation from Agile Academy Australia in the form of a video: https://www.youtube.com/watch?v=0FbnCWWg_NY
2.Use Universal Scoring Formula — Do a relative estimation to each of your tasks but instead of the ambiguous “bigger” estimation, estimate each task in terms of business impact, complexity and time. I strongly encourage you to read what I’ve written about this method here.
But I still need to know how much time it will take!
Ok, I hear you! Here is how to calculate it: Let’s suppose you’ve scored your first task to have time score of 4. You do the job and it takes you 2 days. You can safely derive a correlation between score and astronomical duration — 1 point is 1/2 of a day. So the next time you score a task and estimate it’s time score of 6 you will know that it will most likely take you 3 days. Multiply the sum of your estimated time scores by the duration of a single point and you have the duration of all your tasks.
Warning: Do not start thinking of the astronomical duration first and then assigning the relative value based on it — it defies the purpose!
What to do next?
Make sure you try it yourself first. Try it with your last task and the next few and see the results. For better result add a field in your task management tool to indicate time score/points. If you don’t have a task management tool or your tool does not have a points field make sure to check out Swip — it does it brilliantly out of the box. Try it now while it’s free ;)
