I recently attended a class on estimation. While I believe in the value of estimating I am extremely wary of making too big of science out of something that is inherently imprecise. The course was two hours long which I found to be a perfect amount of time to remind everyone the process and benefits that go into estimation but without over analyzing and over thinking it.
The all too common example
How often do you see or have a conversation between a project manager and developer like this?
PM: "Can you give me an estimate of the time necessary to develop feature xyz?"
Programmer: "One month"
PM: "That's far too long, we've got only one week!"
Programmer: "I need at least three"
PM: "I can give you two at most"
Uh oh. What do you think is going to happen? If you find yourself in these situations take a quick look at the definitions and relationships of an estimate vs. target vs. commitment about halfway down this page here so you and your team can have more productive conversations in the future. It's a short couple of paragraphs.
Fortunately for my team we do not have too many of the above, ludicrous, conversations, so we didn't have to dwell on this topic.
A succinct graph that resulted in very different conclusions
During the training a graph was shown to us to stress the importance of having a precise estimate. I crudely reconstructed it in MS Paint for your viewing pleasure:
Graph adopted from McConnell, Steve, Software Estimation: Demystifying the Black Art
The point of this was to show that having a precise estimate is what you want to aim for. I disagree. In fact, I would argue that we should aim somewhere to the right of a 100% accurate estimate.
Why? Estimation is an inherently imprecise science. Though there are many, many ways (perhaps more than necessary) to become better at estimating, there will always be a cloud of uncertainty. I agree that to be 100% precise on every estimate is best on paper but in practice we'll never get there
Not only that, but the cost of underestimating is huge. We went through some examples:
- The project could fail (worst case scenario).
- Late nights at the office
- Stress and anxiety
- The project could be delayed
- The quality suffers
- The cost increases
- Customers get upset
The distinction between bounded and unbounded results is important. When people overestimate, the feature will still get done, just at the expense of wasted time. When people underestimate, it's possible that the feature will never get done.
Later in the training do you know what was cited as one of the reasons for errors in estimating?
Too much chaos in the project to derive accurate estimates.
Do you know what causes chaos in a project? Behind schedule projects! This sounds like a perfect recipe for disaster, and this phenomenon is known as a positive feedback loop (which despite its name, is not always a positive thing).
Another big takeaway in the estimation training was to always give a range. I'm not going to argue on the benefit/cost of doing that, but if you want more information, perhaps start here. As an example to my point, let's use a range to estimate a feature that turned out to be underestimated:
And an example where it turns out we overestimated:
The area under the curve which represents effort, cost and schedule is drastically less when you overestimate than when you underestimate your features.
Again, I agree that 100% estimation accuracy is ideal, but the costs of being wrong are too high in practice.
How often is your team staying late? How often are projects running behind? This line buried in the middle of this scary, heart-wrenching article was especially poignant to me:
Per usual in software development, the project was behind schedule. It was no time for anyone on that team to be slacking off.
I hate this idea that's so pervasive in our industry. I reject this mentality. It's not fair for anyone that software projects are so "typically behind schedule".
With all these thoughts in mind, it seems to make the most sense to aim for precise estimation accuracy, but more importantly, err on overestimating.
Hate estimating? Love estimating? Do you think it's helpful or useless, or somewhere in between? There is plenty of discussion over here or in the comments section of this article (A preview: most developers don't like estimates at all, for many good reasons.)
Or leave a comment below.
: There's plenty of discussion around the trade off between estimating / time it takes to estimate. My training instructor said that there are rapidly diminishing returns after estimating a feature more than three times.
: Otherwise known as an integral in calculus
: I also found this little fact in this article on estimating that states:
...developers already tend to be 20%-30% too optimistic [in estimating]
which I certainly believe anecdotally. In other words developers generally underestimate. Fog creek actually makes the case to ignore business needs in order to avoid falling into this trap of underestimating.
: I am aware that if I consistently overestimate, and then my project manager takes that result and overestimates on top of that, and then her/his project coordinator takes that and overestimates that value, the final estimation can be drastically overestimated. I wonder if that's actually so bad in practice vs. the alternative.
: I propose that someone somewhere should inflate their estimates by some amount, and the developer is a good candidate since they're prone to underestimating.