Project Management

The Art of Guesstimation: Estimation on Software Projects

From the Disciplined Agile Applied Blog
This blog explores pragmatic agile and lean strategies for enterprise-class contexts.

About this Blog


Recent Posts

#NoFrameworks at Agile Middle East 2020

The Art of Guesstimation: Why Shouldn’t We Estimate?

The Art of Guesstimation: Why Should We Estimate?

The Art of Guesstimation: Estimation on Software Projects

Planning: The Efficiency Zone

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:

  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.



Posted on: December 14, 2019 07:50 AM | Permalink

Comments (18)

Please login or join to subscribe to this item
Dear Scott
Interesting reflection on the topic
Thanks for sharing

You haven't published in a while.
Everything is fine with you?

Interestingly this article begins with an estimate: "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."

The 4 points mentioned about the challenges facing software development teams are very important.


Yes, agreed with your views on guesstimate and real challenges we face in our PM world. Look forward for your future postings. Thank you.

Can't wait to see how your "agile team of guesstimation posts" (7 /- 2 :-) ) evolves, Scott!

I've always taught students in my PM and agile courses that we don't know what a project will cost or when it will end till the very end. Until then, we are dealing with a cone of uncertainty which hopefully narrows with time.

Luis, yes, everything is alright. I've been heads-down the past month or so with courseware development and delivery. But my work schedule is coming back to normal now.

I was hoping someone would notice that I started with an estimate. ;-)

Kiron, thanks! One of the topics I'll be covering in the series is how to convert get an estimation trend chart for agile teams. If the team is working in a healthy manner you get a cone. If it's not healthy then the trend chart is a complete mess - just like the team's situation.

I commented on Karl Wiegers' recent post ( on estimation:

First learn to estimate your own work. If you haven't learnt to estimate what you are going to do in the coming week, how can you estimate what time your team or project is going to take?

As Wiegers says, it’s a good idea to think how confident you are about your estimate. The less confident, apparently the less you have an idea about what the work will be all about, and you can think what to do about that.

However, ‘calculating’ min and max is superfluous, wasting time, pseudo-scientific, and even contra-productive. While coaching many people and teams I’ve learnt that if we estimate just one number, and compare that number with reality after the work, we can learn very quickly to estimate sufficiently accurately. If we blur the number with a range, the learning is almost non-existent, merely just to cover our asses, but not learning to improve.

So: Estimate your own work of the coming week, in chunks of max 6hr each, and learn at the end of the week from ‘sufficiently’ different results (don’t waste your time on small variations). If you’ve mastered that, you’ll see you’ve understood estimation so much better that you’re now up to larger chunks. See also, which has a link to a booklet about this.

I believe every estimate happens to be a guesstimate of varying degree, except that it gets more accurate with experience of repetition of similar work / expertise on the work package itself.

Whenever I have used the word guesstimation, I have got those stares, as if I have not done my homework enough as a Project Manager. I have stopped using that term for sometime. I have tried to use another term , and it is ballpark figure/estimate. There would be queries then, asking me if I would followup on this and get back with better estimates later.

As you know this topic comes from long time ago. Barry Bohem has made the most consistent work, in my personal opinion, delivering things like "Cone of Uncertainty". I think that you can contribute a lot taking those ideas (it seems to me you are on that path) and help people to understand what an estimations is. the best guess based on the available information and the available time to estimate. Then, to understand that an inherent error is always present. But at the end, and tied to DAD, I think you can help people to understand that is a matter of attitude too, mainly when the result of estimations have to be published.

An 'exact' estimate based of complete knowledge is not an estimate. It's a prediction.
Just like a risk that with 0% or 100% certainty something is going to happen, is not a risk.

Venkatachalapathy, the line between guesstimate and estimate is fuzzy, being determined by how much uncertainty your audience can handle. You hit the nail on the head with your story - if you're being told to come back with better estimates then their ability to handle uncertainty is less than you hope. Sadly, many people who are asking for more certainty than is appropriate will often prefer to be lied to rather than told the truth about the actual situation.

Sergio, yes, cone of uncertainty is coming. So are reference's to Boehm's extensive work in this field.

@"many people who are asking for more certainty than is appropriate will often prefer to be lied to rather than told the truth about the actual situation."

I used this example in my booklet#5 "Timeline.pdf' (see

“But they want more exact estimations!” Well, if you estimated the work to be between 800 and 1000 days of work, but they insist in a more exact number, give them any exact looking figure, like 893 days, or 1093 if you like. If that keeps them quiet, you don’t have to waste more time on determining a figure that isn’t exact anyway. Can I do that? Yes, you can. It saves you time you need for more important things. And we should spend our time only on the most important things, shouldn’t we?

Thank you Scott. In my personal opinion you have a great opportunity for making people to review a seminal item which is estimation. Good to bring to the table that in scence estimations are the best guess you can make in a point of time with the information you have on hand. The big problem for lot of people is forgetting estimations will alwys have a probability of error then they try to achieve certainty which is the the first mistake they make

@Niels: the problem with your approach is you are "throwing garbage under the carpet". Mainly because other thing people mostly forgotten is estimations are not static. We need to update it in a consistent way.

@"Mainly because other thing people mostly forgotten is estimations are not static. We need to update it in a consistent way."
Of course.

Thanks, Scott. Should be an exciting series. We all love to talk about estimating :) Inherent in the name itself, estimate.

Spot on when we think about the rationale behind the estimate and the preception of such. That perception is an interesting paradigm. What is said is often not heard.

@Neils, sadly people are often happy to be told something that is often ridiculous were they only to spend a few minutes thinking things through. Another strategy, as @Sergio suggests, is to educate people on the realities of estimation. Harder to do of course. My typical strategy is to start with a realistic range, then if people push back educate them on the realities of estimate, then, only if I have to, give them an unrealistic answer that they find palatable.

@Sergio, thanks. I agree, estimation is a critical topic that we often have unrealistic expectations of. I suspect that a lot of the management dysfunction that we see in practice is due to expectations that are misaligned with reality.

@Andrew, one of my planned blogs will focus on the delta between what is said and what is selectively heard.

@"My typical strategy is to start with a realistic range"
As you can see in my example, that's what I started with: "...between 800 and 1000 days of work..."
And as indicated in my first comment, I teach people how to handle estimation for their benefit. Estimation isn't a goal, we use it for various reasons, in the end to be successful in less time.
Once people get more confidence in their estimates, they're not afraid anymore to show them to others, live up to them, and, if that's (for a good reason) impossible, tell that way before a deadline rather than a week before.

Great topic. This is a real issue when you need to quote a service to close a deal. Hardly customers feel comfortable with the idea of signing something that will have the real amount later

Thank you for sharing your knowledge, It's an ideal platform to learn from you apart from learning about DA from

Please Login/Register to leave a comment.


"I'm sick and tired of hearing things from uptight, short-sighted, narrow-minded hypocrites. All I want is the truth. Just gimme some truth."

- John Lennon