3 Flavors of Agile Estimations
- What are Agile estimations and why they are used?
- Classic estimates
- Abstract estimates
- Funny estimates
- Comparing estimation scales
- Agile estimations – the conclusion
What are Agile estimations and why they are used?
Experienced readers should skip this paragraph and go straight to the next one. If you feel that you would like to be reminded why estimating work matters, let’s start. First of all, it does not matter if you use Agile or not, estimations serve the same purpose:
- To understand how much effort or resources specific task or project will require to be successfully completed
- To sum up different work units (tasks or projects) and understand full scope of the undertaking
- Plan resources ahead
- Figure out time ranges and delivery dates
- Organize people
- Support prioritization efforts
Secondly, it does not matter if you are estimating how much time it will take you to drive a car from point A to point B or you are trying to budget your new real estate project, you will use same matter and techniques to get the answers. While professional project management employs and requires thorough estimations, a lot is still done as “guesstimates” (low effort, guessing/gut feeling based estimation method).
In this post we will try to do the impossible exercise – compare all the agile estimation scales with classical ones in three factors: accuracy, transparency, effort. And yes, we will use estimations for every aspect.
Accuracy – how detailed an estimation can be given it’s best.
Transparency – how easy estimation is to be understood by other people who did not participate in estimation process.
Effort – how much effort is required to define estimates. This can always be a subject where lower effort = lower accuracy, but we will try to step away from this and assume that some estimation scales require less or more effort to provide targeted accuracy.
From A to F, where A is the best and F is the worst. And yes, second yes, it is extremely subjective. The point is that we believe those letters will be relative to each other, and every practitioner even by picking different evaluations, will still end up with same differences between estimation types. So do your own and try to compare. Ping us the your thoughts and results at hello(symbol)teamhood.com
Classic estimates
Time
On of the most common and the easiest estimation type to understand for stakeholders is time. Hours, days, weeks, months, years or even centuries can be found among all small to mammoth sized projects. The funny part here is that it is also the most subjective type. Time estimations usually are the ones, which tend break the initial scope. Lastly, the toughest problem is that being subjective by nature, time cannot be easily used to sum up and presented as totals. All in all, time estimates are still the easiest to come up with as well as the easiest to understand.
Money
Also, one of the most common estimate types. Extremely important and used by in every aspect of life. Slightly harder to decide, but can have valuable outcomes if fixed by making legal agreements between buyers and suppliers. What is more, a very transparent and well understandable estimation. Biggest problem of money estimates are the that they usually turn out below actual costs. Time is also playing it’s part here, impediments, blocked resources, longer than expected delivery cycles tend to push costs higher.
Feasibility
Slightly less common, but still very important and a classic type of cost estimate. This one tells you how likely your undertaking is to succeed/be beneficial/make sense. Feasibility studies are usually met among large scope projects or project programs. Those studies make sense, because people do not want to take big risks and dive into unknowns. Medical feasibility studies are well known due to life cycles of such enormous projects as well as costs.
Top-down or bottom-up estimation techniques
To improve consistency and break down large undertakings project teams usually take one of the two approaches after breaking down work. Either defining top level estimates first and then trying to fit in lower level estimates or vice-versa. Usually bottom-up estimates require more time but also tend to be more accurate. Top-down is easy when you cannot change scope, but you need to understand how much can you fit in.
Abstract estimates
Majority of abstract estimation scales and types came from Agile estimations and agile techniques which recognized the importance of predictability that enables moving fast and not trading-off accuracy too much.
Agile evangelists long time ago recognized downsides of subjective time estimates and came up with an idea of abstract point estimates. They are called story points, because in Scrum technique, every task is a user story representing some specific need or use case. Hence the name – user story. The biggest innovation here is that story points are relative effort factors which should vary only slightly if estimated by different people. Story point values are usually 0 1 2 3 5 8 13 21… those are Fibonacci sequence numbers where next member in the sequence is the sum of previous two.
T-shirt sizes
Another abstract estimation scale. T-Shirt sizes aim at being understandable and abstract at the same time. Scale is S, M, L, XL, XXL… So anyone who have ever worn some clothing (hopefully that amounts to majority of human population) can easily grasp different effort requirements if t-shirt size is written. Where S is definitely easy one compared to XL. The biggest problem with this type of estimation scale is that it is not trivial when summing is required. So usually works best when employed for small efforts, for example weekly team tasks.
Funny estimates
Brain counter
The recent finding on the vastness of internet wisdom – brain counter where scale is directly mapped to the amount of human brain units required. This is yet to be proven as an estimation scale but still worth noting, because it’s catch’yness can bring favorable results in any tough estimation situation. Scale goes like:
- No brainer – easy and should be automated
- One brainer – individual task
- Two brainer – a task for a pair of people
- Multi brainer – mob effort
Comparing estimation scales
Let’s compare all of the scales from above, in three different categories such as: accuracy – how likely estimate is to be accurate, transparency – how easy it is for each individual to understand it, effort – how hard it is to make the estimates (time, energy, people count).
Disclaimer: this comparison is very subjective and for the sake of discussion point.
| Scale | Accuracy | Transparency | Effort |
| Time | C | B | A |
| Money | B | A | B |
| Feasibility | C | F | F |
| Story Points | A | C | C |
| T-Shirt Sizes | A | A | B |
| Brain Counter | E | E | C |
Agile practice estimations – the conclusion
As far as this goes, we can see that some estimation types can be chosen purely because of being easy to do and understand while others require effort but can give fruitful results for later. Finally, each situation require different approach. Smaller risk can use easy to make scales, while big risk project programs require thorough estimation and studies, where scrum teams usually are some where in between with medium easy but accurate metrics to live one of the values of being predictable at a sustainable pace.
Last and most important part of any estimation technique is continuous improvement. To have good understanding how to improve, one needs to measure the performance estimations. Be it money, time, story points – everything can be tracked. Integrated project environment tools can be used to make life easy – just like you can track time, or review actual vs estimates reports in Teamhood.
2019 - Present Co-founder and CEO @ Teamhood.
2015-2019 Head of software engineering department at Danske Bank.
2017-2018 Partner Associate Professor at Vilnius University. Lecturer of Software Architecture course
2011 - 2015 Managed numerous smaller IT teams at Prewise.
Co-founder of RaveIT, Eylean, No Brakes Games
Certified Agile product owner and practitioner. Managed large scale enterprise projects as well as launch of small startup products.
MSc of Software Engineering at Vilnius University.
Hobbies: Racing, MTB cycling, Windsurfing
