In The Art of Guesstimation: Why Should We Estimate? we explored the reasons for why it can make sense to estimate the cost or time that an endeavor will require. But this isn’t the whole story. An important principle of business analysis, and in project management for that matter, is to not only define what is in scope but also to indicate what is out of scope. The implication is that it also makes sense to explore why we shouldn’t estimate an endeavor, which is the topic of this blog.
There are several reasons why we should consider reducing the amount of effort we put into estimation if not eliminating it entirely:
The point that I’m making is that although we’ve seen that there are reasons why we what to estimate time and cost there are also reasons why we don’t. A fundamental observation of the Disciplined Agile (DA) toolkit are that there are no “best practices,” that every strategy has strengths and weaknesses, that every strategy makes sense in some situations and not others. This observation applies to estimation, just like it applies to everything else.
In the next blog in the series we will work through why estimates are probability distributions.
In the previous blog in this series, The Art of Guesstimation: Estimation on Software Projects, we explored the differences between guesstimates and estimates, and in this blog I will use the term estimate to refer to both. Because estimation isn’t limited to projects I will use the term endeavor to refer to efforts that are organized either as a project or as a non-project. As Simon Sinek suggests in Start With Why: How Great Leaders Inspire Everyone to Take Action we should start by explaining why something is important. From that point of view, it makes sense to ask why should invest the effort to estimate the time or cost of an endeavor?
Estimates are often required for several reasons:
To summarize, there are several reasons why we should consider investing the time and money required to produce estimates. In the next blog in this series I will explore reasons for why you don’t want to invest effort in estimating.
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.
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:
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:
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 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.