Note: This blog post was originally written when I was a consultant for OpenSource Connections.
Earlier this year in my MSMIT classes at UVa, we talked about software estimation techniques, which was a very interesting topic.
One thing we talked about was the “Cone of Uncertainty”, as described in Steve McConnell’s book “Rapid Development.” You can read the full description of the cone of uncertainty on the Construx website. Here is a drawing of it as depicted on that website.
The Cone of Uncertainty is a convenient way to think of how software estimation works. When a project is first beginning, you know very little about it and so you should never give customers a single point estimate. A single point estimate just means that you supply one number, like saying “this project will take 6 months.”
Giving estimates in ranges instead is much more valuable and realistic. This more accurately conveys to your customer the uncertainty of an estimate, and therefore the risk. For example, if I give you a wide estimate like “this will take 3-12 months”, that is a very clear way to communicate that we don’t know enough yet to give a firm estimate.
The Cone of Uncertainty shows that the more you know about a project, the more you can narrow that range. So while I might initially think it’s 3-12 months, after spending time analyzing the project, I can revise that to a more narrow range, like 6-8 months perhaps, or 10-12 months.
But what about the end of a project? The Cone of Uncertainty says that the closer you get to the end of a project, the more likely you are to know exactly when it ends. That makes sense in theory, but is it realistic?
I would suggest that many times, there is a large amount of uncertainty at the end of a project, even if it’s well run. Imagine that you are two weeks away launching a new site, and you are still working out some bugs that your testers have found. You know you only have a few bugs left, so you confidently assert to your boss or customer that you’ll be ready to launch in two weeks. Each day you are fixing bugs, but the testers keep finding new bugs. Perhaps they are even finding new bugs faster than you are fixing them, or their rate of finding bugs is not decreasing.
When you had a short bug list in front of you, you felt very confident about two weeks, but now you are less certain. How many more bugs will testing uncover? Your confidence about the time left to launch is now decreasing, and you have to go back to your boss or client and ask for additional time.
The Cone of Uncertainty captures risk at the front end of a project very well, but it doesn’t capture the risk and uncertainty at the back end of a project.
There’s one other thing that also makes me feel like the Cone of Uncertainty is perhaps a bit simplistic. In my classes, we discussed using the Cone of Uncertainty as a way to educate our bosses and clients about why estimates are inaccurate. The idea was to sketch it out on a napkin or whiteboard, and use it to convince them why you can’t give them a set estimate up front (“6 months”), but instead need to estimate in a range (“3 – 9 months”).
However, I believe the problem is that the Cone of Uncertainty implies that you will converge on a middle point most of the time. While that is not the intention of the cone, it still can appear that way because of the way the cone is drawn. So if your boss wants to be tricky, he can play games with the numbers. If you tell him that a project will take 3-9 months, then he may just translate that to mean 6 months (the midpoint of your range.)
But how often have your range estimates actually converged on the midpoint? I would speculate that most of the time, they actually converge on something above the midpoint. That’s because our initial reactions are almost always optimistic, so as we learn more about the project’s complexity which we had not originally anticipated, then we are likely to settle on a point higher in our initial range estimate.
So I would further suggest that it’s better to draw the cone as not converging on a midpoint. At some point in time, your estimates are likely to converge on an estimate that is higher than your original midpoint. This leads me to my humbly suggested variation of the cone of uncertainty, which I like to call “The Wormhole of Reality.”
Why the wormhole of reality? When the cone is redrawn like I’ve done above, it just looks more like a wormhole than a cone. I’m referring to the wormholes of physics and astronomy, where it is a shortcut through space and time. There’s no correlation between the meanings of wormholes in space and my estimation wormhole, it’s just that they look similar. Plus I think it’s a cool name.
But more importantly, how do we avoid getting sucked into “The Wormhole of Reality”? If the Cone of Uncertainty is ideally the way we want our estimates to work, then we want to avoid the “fuzzy back end” of a project. As I already suggested, the fuzzy back end is driven by continual bug reports that seem like they may never end. Here are some tips to try and close out your projects more predictably:
- Use test driven development to write your unit tests early.
- Use browser based automated testing tools like Selenium to automate user level testing.
- Keep your continuous integration server happy and well-fed with frequent code check ins, so it can feed you bug information earlier rather than later.
- Engage users in your system testing early on. Make sure that you deliver incremental releases of your code, at least to internal users and testers, well before the final weeks of your project.
- Engage customers in those incremental releases too. If your internal users are not an accurate representation of external users to your code, then identify some beta customers who would be willing to try out future versions of your product.
- Consider incorporating regular user-experience testing with beta releases of your product, on a feature by feature basis. This is another way to get additional feedback about the code you are going to deploy.
- Use agile methodologies to drive all of the above recommendations.
While the “Cone of Uncertainty” is an easy way to explain to managers and clients how to estimate software development, too often we fall into development traps and end up in dangerous territory like “The Wormhole of Reality.” But by following best practices, and clearly communicating to customers the risk at the front and back end of a project, you will be more likely to avoid these pitfalls and deliver your software on time, on scope, and on budget.
