“How long would it take to do this?”
“How hard would it be to make this change?”
If you’re starting to get angry and frustrated, you’re probably a software developer. Estimation is painful, especially when the person asking you to estimate a task (Let’s call them ‘Bob’) just has a rough idea of what they’re asking for. A lot of this pain is caused by a difference in what Bob wants and what you think Bob wants.
Estimates are not a goal
As a developer, I think of an estimate as “How long, on average, will it take me to accomplish a task?” I’m frustrated because I usually don’t have enough information to answer that question, and I know I’m going to be held to what I say. I assume that my ability to hit this estimate will be an indicator of my overall performance, so I get stressed and annoyed.
They’re a communication tool
Any product that ships has things that depend on it. Depending on how large the company is, it could be marketing, publicity, business analysis, future product planning, or lots of other things. This means that the answer Bob is looking for is “When can I start assuming this thing will be done, so I can start planning things that depend on it?”
I’m answering with “This should be done by…”, but Bob is looking for a “This will be done by…”.
David Bryant Copeland has a great book, The Senior Software Engineer, which talks about this in its first chapter:
A senior software engineer is trusted and expected to do the most important work and to do it reliably. The way to accomplish that is to focus everything you do on the delivery of results.
Keeping that in mind, it’s best to meet Bob on his terms. This means that:
Estimates should be made at 90% confidence, not 50%
Bob wants to know when he can start planning things that depend on the work being done. If this means that the estimate needs to be padded (it probably does), that’s fine. If this means you have to get back him in an hour or two, that’s fine too.
Estimates should be based on time-to-ship, not time-to-test-handoff or time-to-deploy-queue or anything else
This goes back to the focus on the delivery of results. If Bob is waiting for a project to ship, it does no good to him if it’s stuck in QA. This usually means the estimates need to be padded again, which is fine.
The best estimate is often “I can’t answer that now, but I’ll get back to you.”
It’s much easier to get to a 90%-confidence time-to-ship estimate if the estimate is broken up into smaller parts, each of which is easier to understand. Many books discuss the tactics of making accurate estimates, but it’s out of the scope of this post.
What if I’m told that I’m not moving fast enough?
Everywhere I’ve worked, I’ve been told that management wishes we could move faster. No matter how fast products are delivered, even if quality is completely sacrificed, even if the estimates are absolutely insane, even if you work 20 hours a day, management will still wish you could move faster. It’s the job of a developer to see that it’s just a wish and do their job of keeping a fast but maintainable pace, being predictable, delivering results, and keeping a high bar of quality.
What about when I beat my estimates by a hilarious amount and it looks like my estimates are incredibly padded?
I’ve never seen someone who regulary overestimates get punished for it, and it’ll pay off the next time you have a project that goes much longer than you expected. Overestimation by a given amount is much, much better than underestimation by the same amount (I think it’s probably similar to Loss Aversion). Most of the time, there will be a backlog and you can start the next task earlier. Great!
If you targeted the 50% case, unexpected complications could demolish an entire product schedule. You’d do that about half the time! If you target the 90% case, even if things go badly, the rest of the schedule can operate as intended. The product ships on time, everyone’s happy, you get raises and promotions and the best reward of all: You get to make more estimates!