At the beginning of nearly every project time is spent estimating how long things will take, what they will cost and what they will produce. This is done time and again despite nearly everyone involved in the task recognising that the estimates will probably be incorrect. However this doesn’t mean that the process is a waste of time. In her blog Esther Derby proclaims that “estimating is often helpful, estimates are often not“. Her position is that estimating helps when, “the process of estimating builds shared understanding among the people who want the work done and the people doing the work” and that this shared understanding is valuable for all parties. In essence, the process of estimating kick-starts the conversation about what we are trying to do and why, and evolves it from a statement into a fleshed out concept that is understood by everyone involved in the estimation process. You don’t need to have estimation as your goal to do this exercise, but it gives the conversation focus and forces all parties to agree terms e.g. this is what we mean by ‘payment system’.
The problem, as Esther sees it, is when estimates are turned into targets and targets become the measure of success. This results in teams working towards finishing something on time and meeting some financial cost target as opposed to finishing something which will be useful and deliver value for the investment made. Not to mention the fact that it opens the door to arguments, blame and thus a collapse of trust and collaboration.
While there are some tools dedicated to helping with the process of estimating, most of of the time estimation is judgement-based, as the tools are dubious at best, and totally reliant on the knowledge and understanding of the people using them. Someone who has worked on a lot of projects, understands the business domain, technology being used, people in the team and tasks involved in this project and can estimate the time it might take develops up the estimates based on their seasoned judgement. This might sound about as effective as waving a finger in the air but actually it can give you results comparable to using formal estimation models (after all the models require judgement to produce their inputs in the first place). It also has advantages with specific situations or concerns. For example, if you know that the lead developer and project manager in a team don’t get on, that will affect your estimate, and may be something not picked up by a model (although hopefully you work in an environment in which everyone gets on brilliantly).
On the other hand, judgement based estimates are subject to individual bias, inconsistency and wishful thinking, so beware. Finally politics (as always) plays a part. While it seems crazy to reduce your estimate because upper management tell you that your thoroughly researched estimate doesn’t fit in with their plans, it happens all the time, and once you meet an ‘unrealistic’ target once you may be expected to perform the same miracles over and over again.
One of my favourite terms within estimation is the ‘Cone of Uncertainty’ (I always imagine a literal cone and to me cones mean ice-cream!). In the world of estimation the Cone of Uncertainty refers to the narrowing of the uncertainty of a project as it progresses. “At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease, reaching 0% when all residual risk has been terminated or transferred. This usually happens by the end of the project i.e. by transferring the responsibilities to a separate maintenance group.”
The Cone of Uncertainty is a pretty easy-to-understand concept – the difficulty comes in trying to reduce the cone and come up with more accurate estimates. Since the uncertainty is reduced over time the obvious answer is, wait another week to give your estimate. If only it were that easy! As Construx (Steve McConnell, author of Software Estimation: Demystifying the Black Art) point out on their website the only thing that can reduce the Cone of Uncertainty is to refine the software’s definition, “the reason the estimate contains variability is that the software project itself contains variability. The only way to reduce the variability in the estimate is to reduce the variability in the project itself.”
If you are interested in estimation (or indeed any element of software development) SoftEd’s Fusion conference this September is a fantastic event to attend. There will be a two and a half hour workshop specifically on the topic of estimation – Estimation: How to Identify and Address Key Risks to Develop Successful Estimation Approaches – which provides both practical tips and the underlying understanding of where most people go wrong with estimates, thus helping you to avoid making the same mistakes. According to Anja, Sharon and Shane people don’t estimate the right things, which means that their estimates don’t tell the full story. They will undertake a Root Cause Analysis with the session participants which gets at the heart of what you should be estimating. Once you understand this they will provide tips, tools, guidelines and checklists which you can use in your projects to improve your estimation approaches and outcomes.
One of the key elements of this workshop is to help you understand how to establish the level of confidence you can have when making an estimate. Sometimes you can say two weeks and mean a rough guess, sometimes you can say two weeks with absolute certainty. The things you learn in this workshop will help you to understand how and what you are estimating, allowing you to communicate your estimates with clarity and confidence.