A Practical Guide to Answering This Question in an Agile Project. Software project estimation is hard. But our stakeholders need answers. In this presentation we seek to give our stakeholders the information that they need.
Estimates are guesses. Look up the word in the dictionary – An estimate is a rough approximation or calculation, in other words a guess. Unfortunately, too many people think that estimates are promises, or worse yet guarantees. In our opinion “guesstimate” is a far more appropriate word than “estimate”. Scope on IT projects is a moving target. Our stakeholders struggle to tell us what they want and even when they do they change their minds anyway. Any guesstimate based on varying scope must also vary in kind. Guesstimates are probability distributions. More on this later.
Guesstimates must reflect the quality of the inputs. A guesstimate needs to reflect the quality of the information going into it – if your scope is fuzzy your guesstimate based on that scope needs to be equally fuzzy. Sometimes stakeholders want a guesstimate with a tight range, perhaps +/- 10%, early in a project. To provide a tight range such as this you need to have a very good understanding of the requirements and the design. Early in the software development process this can only be done through more detailed modeling, an expensive and risky proposition which often proves to be a wasted effort because the requirements will evolve over time anyway. Guesstimates anchor perception. The primary danger of providing guesstimates to people is that they believe them. Tell someone that it’s going to be $1,000,000 and they fixate on that cost even while they are changing their minds. Tell them that it’s going to be between $750,000 and $1,750,000 and most people will fixate on the cost of $750,000. Some people will focus on the average cost of $1,250,000 even though the median was $1,000,000 (guesstimates are in effect Weibull probability distributions).
It’s easier to guesstimate small things. That is obvious. It’s easier to guesstimate work you’re just about to do instead of work in the distant future. It is much easier to identify the details of work to be done right now, and thus turn a large piece of work into a collection of smaller pieces that are easier to guesstimate. In part this is because you have a much better understanding of the current situation you are working in and in part because you are more focused on the here and now. The people doing the work will likely give a better guesstimate. They are more motivated to get the guesstimate right, particularly when they must commit to it, and have a much better idea of their abilities. Granted, someone may need to coach people through the guesstimation effort. In Disciplined Agile this is a responsibility of the team lead.
Someone who has done the work before will give a better guesstimate than someone who hasn’t. Experience counts. Guesstimates reflect the situation that you face. Which organizational situation do you think will result in a short schedule and lower cost: Five people co-located in a single room or the same five people working from different locations in difficult time zones? Or how about a team working under regulatory constraints versus the same team without those constraints? Context counts. Multiple guesstimates are better than a single guesstimate. Getting guesstimates from several people provides insights from several points of view, hopefully prompting an intelligent conversation that enables you to develop a guesstimate with better confidence. Similarly, the same person producing guesstimates for the same piece of work using different guesstimation strategies will also provide a range of answers that you can combine.
Guesstimates should be updated over time. As your understanding of what stakeholders want improves, and your understanding of how well your team works together, you should update your guesstimates. As your understanding of the fundamental inputs into your estimate improves you are able to produce a better estimate, thus enabling the stakeholders of that guesstimate to make better decisions. It costs money to produce a guesstimate. The precision of an estimate is driven by the detail and stability of the information going into it. Want a tighter range on your estimate? Then you’re going to have to have a better handle on the requirements, design, and capabilities of the team doing the work. This greater precision requires greater cost. The fundamental question posed by the #NoEstimates community is effectively “Is the value of improved decision making capability from having the guesstimate greater than the cost of creating the guesstimate?” The implication is that you must ensure the cost is much less than the benefit, hence their focus on finding ways to streamline and even eliminate the guesstimation effort.
Guesstimation is far more art than science. See point #1 about estimates being guesses. The best guesstimates are done by the people doing the work, just before they need to do the work, for small pieces of work. Formal software guesstimation schemes are little more than a scientific façade. Function point counting, feature point counting, and COCOMO II are all examples of formal strategies. They boil down to generating numeric guesses from your detailed requirements and design, plugging these guesses into an algorithm which then produces a guesstimate. These are all expensive strategies (they require detailed requirements and design work to be performed) that prove to be risky (because they often force you into a waterfall approach) in practice. Yes, they do in fact work to some extent, but in practice there are much less expensive and less risky strategies to choose from. People like these type of guesstimation strategies because they provide a false sense of security due to their complexity and cost.
Past history isn’t as valuable as people hope. Some formal guesstimation strategies are based on past history, but this proves to be a false foundation from which to build upon for several reasons. First, people have different levels of capability which change over time as they learn. Capers Jones has shown that developers have productivity ranges of 1 to 25, the implication being that if you don’t know exactly who is on a team and how well they work together your corporate history will be questionable. Second, technologies evolve quickly so past history from working with older versions of technologies or completely different technologies becomes questionable at best. Third, people and teams change (hopefully for the better) over time, implying that an input into your guesstimate is fuzzy at best. Fourth, because every team is unique and faces a unique situation basing estimates on past history from other teams in different situations proves questionable. Beware professional guesstimators. They tend to break many of the rules we’ve described above.
Big Ideas: Best option is an educated guess Worst option is cost/schedule being set by stakeholders