The Effective Estimation Series

One of my courses is Effective estimation in which I teach people the basics of how to estimate effectively.

In parallel with this, over on my newsletter I’m in the process of writing a more comprehensive series about estimation, its theory and practice. This page mostly serves as an index and overview for it.

How to think about task estimation

This is the opening post of the series in which I talk about the basic problem: Estimation is an attempt to collapse uncertainty, to take a complex process that could produce any number of different outcomes, and reduce it to a single number.

This isn’t intrinsically a bad thing to do, but you are unable to do it well without asking a single basic question: Why do you want to know? Without asking this question, you don’t know how much different risks matter, and you can’t make plans based on the number. For example, the questions “Roughly how much will this cost?” and “Will it be done by this deadline?” result in very different sorts of estimates, with estimates you can rely on for the latter typically being much larger than the former.

This post elaborates on these concerns, and provides some tools for understanding them and working with them in practice.

How to pick a number for any purpose

This post provides a basic set of tools for estimating, both time and other quantities: Pick a plausible lower bound, a plausible upper bound, and make your best guess within that range based on the considerations of how the estimate will be used.

This technique is only modestly effective, but its real power is not that it produces amazing estimates, it’s that it produces estimates fast, and by making you think about some basic considerations it tends to reduce a lot of the anxiety and difficulties of producing fast estimates.

As such it’s an essential element of any estimation toolkit, and is the “technique to beat” - if you want to put more effort into estimation, you’d better be sure that the improvement in estimation quality over this method is worth the effort you put in.

Estimation is inseparable from planning

This is a post about several big things that can go wrong in estimation:

• You underestimate how much events disrupt your schedule due to people being exhausted by them (e.g. a big launch)
• You didn’t realise you needed to estimate something (e.g. provisioning for servers turns out to be much more expensive than you’d thought plausible)
• Completely unexpected events mean that your plans have to be revised from scratch, totally throwing off your schedule.

Which is to say, it’s the story of me moving flat, and all of the places I really should have estimated better in the course of doing so…

How to think about estimation strategy

One of the problems with estimation is that you never really know if your estimate is right. We saw in earlier articles that what estimate you give is intrinsically tied up with what you want that number to do, but once you know that how do you estimate better? If you decide you want, say, the 99%-ile estimate, how do you know what the 99%-ile is.

The simple answer is that you don’t, and you can’t. It’s not that you’ll ever learn a number that is the true value of the 99%-ile, instead you are trying to skillfully play a game with a particular scoring rule, with the scores determined by the real world consequences of different sorts of errors. You’re trying to learn to score well in this game, which requires learning its strategy.

There is no perfect strategy, as in almost any interesting game, but importantly there are also very easy strategies (e.g. the “decent first guess” strategy from “How to pick a number for any purpose”), and you can use this viewpoint to judge whether one strategy is better than another, and use that to improve while avoiding any of the deep existential questions about whether you’ve got the “right” estimate.

Upcoming posts

Future posts will include more on philosophy of estimation, practical strategies for communicating around it, simulation and its uses, and as little probability theory as I can get away with teaching (which is alas probably not going to be none).

I don’t yet know exactly when the series will be finished. I’m currently anticipating at least four more posts, but the scope on that is liable to expand. I will definitely not publish these faster than one a week, so that puts early October 2022 as the absolute earliest the series could be completed, but I think it’s more likely to wrap up in late December 2022, and it’s not impossible that it will spill over into the new year.

And yes, that is how you should answer “How long will it take?” in most cases.