The Art of Guesstimation: Estimation on Software Projects

 

This is the first of several blog postings that I'm going to write on the Art of Guesstimation.  I guesstimate that I'll be writing 7 +/- 2 postings on this subject, depending on how our conversation progresses and how I decide to divide the overall topic into blog postings (I currently have a plan but I suspect it will evolve based on feedback).  My eventual goal is a detailed article on the subject, likely sometime in February 2020.

Guesstimation?  

You've liked noticed that I have been using the term guesstimate rather than estimate.  This isn't a typo.

In early December I was in Las Vegas at SeminarsWorld co-teaching the inaugural Disciplined Agile Lean Scrum Master (DALSM) workshop with Al Shalloway.  One of the topics that we covered was Agile Estimation where I brought up the fact that estimates are often guesses, particularly in the IT space.  This was a bit of a shock for some students as it went against their project management belief system.  Interestingly one student had a story about they had recently had a conversation about this very issue with some of her stakeholders when they weren't given the "exact answer" as to the potential cost and schedule of an IT project they were about to embark upon. 

So let's move away from a belief-based discussion in favour of a fact-based discussion by seeing what the dictionary has to say on the subject.  Merriam Webster defines estimate as:

1. The act of appraising or valuing 
2. An opinion or judgement of the nature, character, or quality of a person or thing
3. A rough or approximate calculation

So, particularly given 2 and 3, there is a bit of wiggle room in our estimates.  Now let's consider the definition of guesstimate, which has been a "real word" since 1923.  According to Merriam Webster, a guesstimate is an estimate usually made without adequate information.  Hmmm.... sounds a lot like the situation faced by most teams in the software space, doesn't it?

The traditional response to the problem of inadequate information is to perform detailed analysis and design early in a project.  In theory this should work, but it flies in the face of several unfortunate challenges faced by software teams:

• Stakeholders are not very good at defining what they want when it comes to intangible things such as software, usually because they just don't know what they (don't) want until they see it (so work incrementally)
• People change their minds when they do see it (so work collaboratively)
• Their actual needs change over time, often due to changing conditions in their marketplace (so deliver quickly and often)
• The solution space changes constantly, with new technologies and platforms emerging on a regular basis (so be technically adept)

None of these challenges are addressed well by detailed, up-front modelling and planning.  The unfortunate reality is that at the beginning of a software project, and I suspect for any project similarly focused on intangible things, the information that we will base our initial estimates on will be vague at best.  This tells us that in the early days of a software project we are clearly guesstimating.  As the project progresses our stakeholders have a better understanding of what they actually need and the team has a better understanding of how they're going to meet those needs.  The implication is that over time we can tighten up our guesstimates until we eventually find ourselves in a situation where the term "estimate" begins to become viable. 

Future Postings

Future postings in this series will focus on how estimates are really probability distributions, what we're really saying when we say "on time" or "on budget", why we should provide ranged guesstimates even though many people still want to hear "exact" estimates, truisms about guesstimation, and how Disciplined Agile (DA) improves upon Agile's classic burn down and burn up charts to provide ranged estimates.