One of the things that has come out of the discussion on #NoEstimates is the notion that estimates provided by development teams are often guesses and committing to guesses is foolhardy. So I’d like to explore the difference between these terms as we know that the language we use to communicate is important.
Webster’s definition of estimate is located here. What I find interesting is that word guess is used a couple of times in the definition. Other searches also provide guess as a synonym for estimate. So I think we should cut people some slack when they use the words interchangeably. That being said, let’s agree that these dictionary definitions are just too generic and are not what are being asked for in software development. Let’s add a little bit more substance and define estimate as:
An approximation/calculation based on the observation of past behavior/performance/data, significant analysis or expertise
and guess as:
An approximation/calculation based on intuition absent of the observation of past behavior/performance/data, significant analysis or expertise
With these definitions, we can make the statement that an estimate is the product of some significant rigor while a guess, has little to no rigor to it. However, many of our guesses are influenced by past behavior, performance or data to some degree. Enter in guesstimate which lies somewhere between a guess and an estimate. (Where exactly, I’m really not sure). It’s important to note that all three can be right or wrong. All three can be useful (or not). They don’t guarantee outcomes. However, we may have more success basing decision making around a meaningful estimate over a guess or guesstimate.
Based on my experience developing software products from scratch, there are generally two classes work found in such environments:
- Work that looks like work we have done before
- Work that is different from work we have done before
If a lot of the work you do falls in the first category, then estimates are probably a perfect fit for you. You most likely have enough historical data to use for your approximations. However, the product companies (commercial and internal) that I’ve been a part of do quite a bit of the second type of work as we add new and innovative functionality to our products. Some will suggest that someone else has done the same thing somewhere, but its not the same as doing it in your own product, with your technology and with your team. No two environments are the same and this is may even be truer for knowledge work environments.
So if you happen to do the second type of work, how do you provide an estimate (not a guess or guesstimate) in the absence of relevant historical data? You will have to use analysis and/or expert judgement upfront. There are estimation books that can provide guidance on these techniques. The point is that there needs to be some rigor upfront in determining the estimate.
I’d suggest that in environments where the work is different from work done in the past, this upfront rigor may not be as beneficial as one may think, simply for the fact that the team is probably “learning as they go”. I realize “learning as we go” does not apply in some environments, but on the teams that I’ve been a part of, we’ve continued to learn about the new capabilities we were delivering even as we worked on them. The degree of learning varies but it still occurs. It’s the nature of the work we do. Your work may be different.
My observation/experience is that guesses and guesstimates are very often provided in the name of estimates for this second category of work. It’s not estimations fault but its what occurs. For example, an estimate provided on how long it will take to fix a bug when its not known what’s causing the bug is probably a guess (or at best a guesstimate). I could be out on island when it comes to this observation but I’d like to think that I’m not alone. I’ve even been guilty of asking for these estimates, um, I mean guesses in my own career.
So when you ask for an estimate, make sure you understand what it is you are actually asking for, how it’s being derived, what it is that you actually receive in return and what is being committed to. Better yet, ask yourself a #NoEstimates question: is an estimate (not guess or guesstimate) requisite to getting the work done in the first place?