Why estimates are always wrong

Why estimates are always wrong

I estimate that most estimates are wrong by around 25%, which means that by that logic most estimates are actually wrong by about 31%.

I would bet that almost every project that developers work on have estimates that make deadlines appear feasible, but ultimately the project always end up going down to the wire, gets delayed, features are chopped or quality is lost.

Estimates being low aren’t the only reason for this, but by their very simplicity they become a tool to give confidence in software delivery where it doesn’t exist. When an estimate of “2 months” is given there are usually many caveats that go with it, but those often don’t get translated into gantt charts or whatever plan is made that would made the writers of the Agile Manifesto shiver from thousands of miles away. In less salubrious establishments, estimates can be used to push people in excessive overtime and assign blame if there are problems. But let’s not assume you’re working anywhere like that!

The vast majority of people need estimates for their projects, so what can you do when asked for an estimate? You can be obtuse about it, you can be incredibly vague about it, you can pull a number of the air or you can simply refuse to answer it but in my opinion the best thing to do is to try and educate your team about it. If they can understand the nature of the estimates you’re giving you can work as team to deal with the problems that the uncertainty causes. There are quite a few techniques to help estimation, particularly story points and planning poker but fundamentally if your business has no idea why estimation is always wrong then they won’t understand the value of any technique you adopt.

This obviously isn’t easy and not even possible in many places. It’s why you’ll often hear about how implementing Agile development isn’t just adding a few stories and a Kanban board, but a culture change.

All I can do to help is try to come up with an analogy of software development estimation so that anyone can understand the challenges faced. If you don’t like my one below, this one by Michael Wolfe is particularly good 🙂

First a quote from Donald Rumsfeld:

… there are known knowns; there are things we know that we know.
There are known unknowns; that is to say, there are things that we now know we don’t know.
But there are also unknown unknowns – there are things we do not know we don’t know.

So here’s the analogy: You’re having an unexpected dinner party (because you’re grown up now) after work on a Friday and your co-host wants to know what time dinner will be served. Because you can only cook one thing, you’re making a quick Spaghetti Bolognese. Here’s your estimate:

  • 6pm – leave work and get on cycle
  • 6:20pm – arrive at Waitrose to get ingredients
  • 6:35pm – leave Waitrose and cycle home
  • 6:45pm – get home and start cooking
  • 7:15pm – everything chopped and cooked and now simmering. Guests arrive.
  • 7:16pm – open wine bottle brought by guest
  • 8pm – that’s long enough, dish up

Simple! 8pm, that’s when dinner is served. Maybe add 15 minutes of contingency, so let’s say 8:15pm.

8:15pm… that’s over 2 hours to get back from work and cook and be eating. My gut (pun intended) feeling is that that’s right.

Here’s what really happens:

  • 6:10pm – leave work (projects never start on time)
  • 6:30pm – get to Waitrose but the normal cycle racks are full (known project risk, but not accounted for in estimate)
  • 6:35pm – finally locked up bike in the corridor and start shopping
  • 6:50pm – got all the bits and pieces but realised 8:15pm is late and people need nibbles to eat (scope creep as requirements become more clear)
  • 6:55pm – grabbed some olives and went through checkout
  • 7:15pm – got home, guests have already arrived so spend a few minutes chatting (meetings aren’t included in estimate, taking away development time)
  • 7:16pm – realise the guest that was bringing the wine hasn’t turned up. (Estimations don’t include contingency for sickness)
  • 7:25pm – get back from shop with wine.
  • 8:15pm – everything chopped and cooked and now simmering, took 20 minutes longer than expected due to increasing inebriation and occasional chatting to guests (being late on a project has unplanned repercussions that cause the project to start running even later)
  • 8:50pm – minimum simmering time of 45 minutes ignored because everyone is too hungry. (Quality often suffers when deadlines are missed).

8:50pm, not bad! Only 35 minutes late. That doesn’t seem too bad except it works out as being 25% over. On an 8 week project, that works out as being 2 weeks over – which potentially an angry client/board or a whole load of overtime.

So, what can we learn from this other than estimation is hard? Order pizza if you’re having people around at the last minute and never rely on other people to bring the booze.

Photo by Felicity Cloake in her excellent article on “How to make perfect bolognese” in the Guardian.