The eternal challenge of (in)accurate task estimation

In 1975 Fred Brooks wrote “The Mythical Man Month” — a book on the various causes of scheduling failures, based on his experience at IBM while managing the development of OS/360.

The book is considered a classic of software engineering and is mentioned by some as “The Bible of Software Engineering”, because “everybody quotes it, some people read it, and a few people go by it”.

But when reading the book nowadays, the most surprising aspect is to realise that, 50 years later, software teams experience very similar issues to the ones described by Fred Brooks.

Pause for a moment to reflect on this: In 2020, software teams still suffer from similar painful scheduling problems that teams in 1975, at the very beginning of software, did experience!

Does this mean that product development hasn’t evolved in this front? No, I don’t so.

The transition from waterfall to agile has decreased the level of uncertainty, by breaking products and projects into smaller chunks, and by acknowledging that its plan and the product itself will change over time.

The standardization of many software practices, through the use of frameworks in every layer — UI, UX, Frontend, Backend — and the standardization of Users’ expectations of software, is resulting in more straightforward development: fewer decisions are needed to be made.

The craft of product development, and Product Management in specific, has evolved and it’s maturing: we’re much more experienced and prepared for the challenges that product development brings.

Nonetheless, when it comes to estimates, it seems to not be enough: over and over again, software teams get behind schedule.

Why is that?

Describing every single cause of wrong estimates and the respective solutions isn’t going to be my job in this post — there are whole books dedicated to the topic which you can check.

Nonetheless, two concepts have helped me considerably to understand why estimates are so challenging and which I want to share with you:

The unknown unknowns

To quote epistemologist and former Secretary of Defense Donald Rumsfeld:

There are known knowns. There are things we know we know. We also know there are known unknowns. That is to say, we know there are some things we do not know. But there are also unknown unknowns. The ones we don’t know we don’t know.

When a product team is asked to estimate the effort for a task, they take into account the “known knowns”: the things they know they’ll need to tackle and which they have a good idea how to handle.

More experienced teams will also account for the known unknowns: the things they need to tackle but they realize they may be unknown challenges when doing it (aka it may be more complex than it seems).

But the biggest wild card in estimates is the unknown unknowns: the things we didn’t even think to exist, much less estimate the time we’ll take to tackle them.

Because there’s so much we can predict will happen, and this fact alone dramatically affects our estimates.

Exploring a new territory

Imagine you were asked to explore a newly found desert, of which you have no map and knowledge of its terrain. The only information you have is a scarce description of its fauna and flora provided by the surrounding population.

If you’re asked how much time you’ll need to cross that desert, what will you say? (3 days? 3 weeks? 2 months?)

How will you be able to give a precise estimate to something you haven’t explored yet, and about which you have just some rough information?

Naturally, your experience exploring other deserts, and the hints from the population will give some clues. But you cannot ever make an accurate estimate from the start: the desert will be smaller or bigger than first expected, with a terrain which is more or less challenging, with different fauna and flora, etc.

To not disappoint your supporters (who are funding the trip by the way) you would probably need to estimate it using a time range, and add a safety margin on top: let’s say, “between 3 to 4 months”.

This is a less precise estimate than initially had in your head “3 months and 6 days”. But it’s definitely more realistic one to provide to your supporters.

Software is similar in this sense.

There are various aspects of product and product development process we’re familiar with, and which help us give an initial estimate. But building digital products is complex, thus making their estimation always imprecise — there can only be approximations of reality.

These concepts show us why.

Unless we’re working on a very standardized solution which our teams have developed countless times: accurately estimating digital products is, and forever will be, challenging.

But as we did and are doing in many other fronts of product development, I believe that through experience, techniques and improvement of our processes, task estimation should slowly improve over time.

I’m Daniel, Product Manager at Whitesmith. Paper Planes is a place where I reflect on my experiences and learnings on the craft of Product Management.

If you enjoy these, please show your love by tapping the clap button!
You’re also welcome to follow me on Medium or Twitter!