Is it not worth planning and estimating because I’ll never hit the target anyway?
In general, people are not good at making accurate estimates, but the good news is that people tend to make more accurate estimates when the scope is smaller.
This happens, among other reasons, because the amount of “unknowns” is significantly reduced, and we face fewer surprises. We can better identify what needs to be done.
This principle was applied, for example, in the construction of the Empire State Building — instead of thinking of it as a 102-story building, it was thought of as 102 single-story buildings. Almost all the floors are the same.
Link to image of Empire State Building
And, this brings us to another area of estimation — people are not good at estimating unknowns — and the Empire State Building was, at the time of its construction, and for the next 40 years, the tallest building in the world.
People are not good at estimating unknowns. However, people are very good at comparing.
What is one of the reasons the Empire State Building was successfully built as expected?
Just one year before, the same company with the same architects built a sister building, which, although only 21 stories high, was essentially a smaller version of the Empire State Building. These 21 stories took almost 2 years to complete, while the 102-story Empire State Building was built in just 13 months — 5 months ahead of schedule.
The Empire State Building was 5 times taller than its counterpart, the Raynolds Building, but was built in 54% of the time.
By the way, speaking of buildings — the Sydney Opera House had an estimated budget of 7 million dollars, but by the end, it cost 100 million, and the estimated construction time was 4 years, but it, actually, took almost 15. There were many reasons for this, but the main ones were:
- Mismatch between the architect and the construction engineers, mainly due to unrealistic expectations.
- The architectural competition was won by a design that was visually striking but lacked a plan for execution and budgeting.
- Complex construction processes that had never been tested before.
So, how do estimates work?
What is the likelihood that your estimate will be correct?
In the book How Big Things Get Done (Amazon link) there is a study that was conducted on 16,000 projects across more than 20 different sectors in 136 countries. From this study came the “Iron Law of Megaprojects.”
Visualization of project delivery ability (How Big Things Get Done)
In short, statistically, only 0.5% of the more than 16,000 projects in the study met all three parameters — they stayed within or required a lower budget, completed the project on time, and delivered the expected benefits. Looking at this statistic, the Empire State Building project becomes even more exceptional.
Only 0.5% of more than 16,000 projects managed to meet the budget, estimated time, and deliver the expected benefits.
How much do projects deviate from estimates?
In project management, terms like “buffer” or “contingency” are commonly used. The most common rule is to add a buffer of about 20%. Even that is not always the case, as businesses may push for a lower price to make the project more attractive, and deadlines also play a role.
So, what is the reality? For construction projects, the average budget overrun is 62%. Does this sound disastrous? Even worse, this distribution is not “normal” but rather a “fat tail distribution.” This means that projects at the extremes are significantly off target.
In the IT world, where many of us operate, 18% of projects have an average budget overrun of 447%.
In other words, when we make an estimate in IT, there’s a big chance that the error will be significant.
So, what can be done with this fact?
Let’s try to connect it with principles applied in the Agile world and Scrum.
Variable Scope
Statistics show that meeting the “Iron Triangle” (budget, time, scope) is highly unlikely, so the question is what elements we can work with. In the real world, it’s rare to have the option to infinitely expand time and budget. Therefore, the last option left is to work with the scope of what we can deliver.
Breaking down into smaller parts
When we know that it is difficult to make accurate estimates, we try to refine them.
And here we get to splitting requirements. By dividing them into smaller functional units, which are easier to estimate due to their size. Because people are better at estimating less complex and demanding things. In larger tasks, they tend to add the aforementioned buffer.
If I am building a skyscraper, estimating the entire building is very challenging, but when discussing the details of a single floor, the foundation, and individual parts, the estimates become more precise.
MVP / MMP – Minimum Viable Product, or Minimum Marketable Product
It allows us to verify functionality, market needs, technology, and at the end of the day, it can even help improve estimates, as we gain experience that we would only get at delivery time.
Almost no one has heard of the Raynolds Building, but without this building, the Empire State Building probably couldn’t have been built in 13 months. The Raynolds Building was the MVP and MMP version. MVP because it helped find an efficient way to construct such a building, and MMP because it was already delivered for use.
Comparing instead of estimating
If we look at the following image, can we say how tall each building is?
But if we ask which building is taller than the other and by how much, anyone can answer. We just need a reference — something we know — and we can estimate much more accurately.
In other words, we are talking about a reference catalog — a list of tasks whose size we already know. When estimating, we not only compare but can also say that this task is roughly twice as big as the reference — just like the skyscrapers in the image.
Repetition of things we know
The learning and repetition effect. If I do similar things, my ability to estimate improves. If sprints always last two weeks, I can pretty accurately predict what can be done in two weeks, even with all the unexpected things that come up. If I do something similar again, not only will I be able to say how long it will take, but I will even be more efficient.
This also happened with the construction of the Empire State Building — each additional floor was built a bit faster until the final speed was reached.
Conclusion
Estimates are necessary not only in Agile but in any planning process, but they are often inaccurate, and everyone has experienced this firsthand. It is therefore natural that people try to avoid something they often get wrong. This is why it’s good to try to incorporate points 2 to 5 to help overcome the barrier and the natural fear of estimates, without which effective planning would not be possible.
