What I Learnt About Estimation

Estimation is hard in software projects. And in all kinds of projects: we hear about metros being years late and billions of dollars over budget for each line. Estimation is particularly hard in software, where you can’t visualise progress.

Why We Should Estimate

1. To eliminate tasks that have low business value but take a lot of time. I spent a month supporting old iPhones in Futurecam, which in retrospect wasn’t worth it. When you estimate, it gives you a chance to take a step back and identify whether something is worth it. The most beneficial form of prioritisation is throwing out some tasks.
2. To order tasks: If two tasks have similar business value, but one takes a day and another takes a week, you should do the former first.
3. To plan better before starting work, by breaking it down into pieces and visualising the changes you need to make. You go through this process when you estimate. And when you do, some problems surface sooner, where they can be fixed much more efficiently than coding something and then redoing it.
4. To give other stakeholders some predictability. But only some. Optimise for productivity over predictability. For example, people often complain that estimates are bad. Well, we can improve our skills, which is a good investment. But estimates still won’t be precise, say to within 20%, as non-technical people who think they’re being reasonable ask. To improve it further, you have to spend significantly more time estimating each task. Say that extra time is half an hour for each task. But if there are 10 engineers in the team, and each does 10 tasks in a sprint, then we’re wasting 50 hours trying to improve estimates! That’s more than a person-week of time, which could have been spent on the actual work. All to please non-technical stakeholders and satisfy their preconceived notions of how work should happen. Project management should be driven by outcomes, not appearances. Optimise for productivity, not predictability.

Estimates Are Guesses, not Commitments

That’s because there are often a lot of questions on the product, UX and engineering sides. Say you’re asked, “How long would it take to implement login?” This brings up a lot of questions: Do we need to have our own passwords, or can just login via third parties like Google and Facebook? Or both? Can we offer just one third-party option, or do we need to offer multiple? What about Forgot Password? That wasn’t mentioned, but does it mean we don’t need it, or was it overlooked, as things often are? Should it be like Medium where you always log in via a link sent by email? You always use the Forgot Password flow, rather than having a normal flow and a Forgot Password flow. Should you be able to login with your phone number instead of email ID?

You can see how many different ways there are just to log in, at the product level.

Then, at the UX level, the designer may design something awesome that takes longer to implement.

Then, at the engineering level, there may be challenges you’re not aware of till you get into the thick of things.

With so many unknowns, an estimate is a guess, not a contract. The purpose of giving one is it to help plan. It should be held against you by saying, “You said it will take a week, but it took two!”

How To Estimate Better

When I’m asked for an estimate, I give what I think is realistic, not what the other person wants to hear. The latter defeats the point of an estimate. If something is going to take two weeks, stakeholders are better off knowing that on day 1, so that they can make better decisions, rather than being told “1 week” and it taking two weeks anyway.

When asked to estimate a milestone, don’t just look at it and say, “Maybe a month!” Instead, break tasks into sub-tasks, till each takes one person-day or less of time. Estimate each sub-task in hours, and total them.

This results in a best-case estimate, what it will take if you’ve identified all tasks, and no unexpected complexity is found in any. This requires dozens of things to go right, and not one wrong. Which rarely happens. Double the best-case estimate to make it realistic. I communicate realistic estimates, not best-case ones, to stakeholders. Because communicating an estimate that almost never is reached doesn’t serve any purpose.

Each task should be estimated by the person doing it. I can launch an Apple app in two days; someone else may not be able to. People are not fungible. The person doing it can take other people’s opinions, but the estimate is theirs. When a person’s name is on the estimate, they get better over time. Whereas diffuse responsibility means no one asks, “How can I get better?”

Once you have an estimate in hours, convert it into person-weeks by dividing by 37. This is assuming each person works 40 hours, minus overhead. Which can be both expected (code reviews, daily standup meetings …) and unexpected (outages, customer problems, …). You can use a different number from 37, but not 40, because 40 assumes no overhead, which doesn’t happen in the real world. And not a number more than 40, unless you want to take advantage of people.

If you want to get better at estimation, record how long something was estimated, and how long it took, and compare them in a spreadsheet. It takes discipline and time to track, time that could be spent doing more work, but that’s the only way to get better at estimating.

Estimation is part of planning a milestone.

Also read What I Learnt About Project Management.