Agile Zone is brought to you in partnership with:

George Dinwiddie is an independent software development coach who helps organizations, large and small, to increase the effectiveness of their software development efforts. He provides guidance over a broad range, at the organizational, process, team, interpersonal, and technical levels. He is currently crusading to break down the barriers that hinder effective collaboration between the business, the programmers, and the testers. George is a frequent speaker at Agile conferences. George is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Another Two Sides to Estimation

  • submit to reddit

There are many ways to look at the issue of estimation. Everyone in the business of software development has had experience with wanting estimates, being asked for estimates, or both. That experience frames how they look at the issue. A considerable share of those experiences have been painful. I dare say that everyone in the business has had some painful experiences around estimation, and the painful ones seem to stick in our memory more vividly than the benign ones.

What makes these experiences so painful? Again, the causes are legion. One frequent contributor is well illustrated by a story my older brother taught me as a child.

A world-famous bricklayer announced he was ready to put away his trowel and retire. Upon hearing this, a rich man approached him to build a mansion. He could spare not expense and build it any way he wanted. The bricklayer thought this was a wonderful way to retire, with one last crowning masterpiece, and agreed to do the job.

He studied the plans that had already been made, scribbled notes on them, and made some new sketches. He toured the building site, compared it with the surveyor’s plat, and did some calculations. After months of study and consideration, he ordered exactly the number of bricks he needed for this final masterpiece. Within days, the bricks were delivered and he went to work.

Day after day, the bricklayer rose early, worked hard all day, and didn’t stop until the light was starting to fade. He worked alone with his hod carrier, so that no lesser hand would mar this magnificent mansion. Like a mad demon, he turned piles of bricks into walls and turrets, until finally he was done. Done! His perfect masterpiece was done.

He backed away to view the full glory of his work. In doing so, he tripped and stumbled. Getting up, he noticed that what he’d tripped over was a brick.

A brick? A brick! There was a left-over brick. That could only mean one thing. He had made a mistake and left out a brick. The bricklayer worriedly ran around the worksite, checking this place and that, looking for where he might have omitted a brick. Everywhere he looked, he could find nothing amiss.

At last he stood in the middle of the construction, brick in hand, and started to realize what had happened. He had failed in his final project. He had ordered one brick too many. Mortified and furious, with all his might, he threw the brick straight up into the air!

This simple story illustrates so many ways that estimation is misused.

  •  Estimating a precise value without contingency for unknown surprises
  •  Judging the estimate by the actuals, as if we should know in advance what we know later
  •  Judging the work by the correspondence to prior estimation rather than by the outcomes
  •  Becoming angry when the actuals don’t equal the estimate

Does this remind you of situations where you work? I think we’ve all seen these dysfunctions, even if not to this extreme. Considering such behavior, it’s no wonder that people would like to avoid estimation if they can. Unreasonable expectations of what estimates can do, or what the estimators should do are all-too-common. Such unreasonable expectations often result in developers, or anyone asked for estimates, to dig in their heels and try to avoid providing them.

This reminds me of another story.

A man and his wife found that their lives had grown apart over the many years that they’d been married. Each did the things that interested them, and they did little together. The man thought he would surprise her to bring them back together. Secretly he took flying lessons until he got his pilot’s license. Then he rented a small plane and invited her to go flying with him.

He was delighted that she agreed, but as they were leaving she picked up her cat and brought it along, too. The cat that didn’t like him. He didn’t say anything, and they drove in silence to the airport.

After takeoff, he excitedly pointed out the places they knew. “Look how small and different they look from up here!” She murmured, petting her cat. He looked over and noticed she wasn’t even looking out the window when he pointed. That cat meant more to her than anything he could do. He started to get upset. That cat was his biggest rival. Angrier now, he thought, “That cat is the cause of all our problems!”

With one quick move, he grabbed the cat and threw it out the window. “That solves that problem,” he thought. He smiled and leaned back in his seat. He reached into his pocket for one of his last few Cuban cigars and started to smoke it.

At this moment, his wife started to come out of the shock of seeing her cat thrown out the airplane window. Not knowing any other way to get even, she grabbed his cigar and threw it out the window, too. Now, both of them were angry. Neither looked at the other and they flew back to the airport in silence.

Still not speaking, they climbed down from the plane. Then they stopped, amazed. There, clinging to the bottom of the wing with its claws was the cat. And what do you think was in the cat’s mouth? (hover here for the answer)

This story illustrates why estimates become so painful. It’s not the quality of the estimate that makes it so. It’s the fact that those asking for estimates and those asked for estimates (or provided estimates to which they’re expected to conform) each value different things, and ignore the value that the other prefers. They want to get what they want, and are willing to throw out the window those things that are valuable to others.

The path to less-painful estimates lies not in better ways to estimate, or in eliminating them. It starts with understanding each other, what’s important to us, and what we can accomplish. The problem of painful estimation is not about the estimates. It’s about the people and their relationships.

Published at DZone with permission of George Dinwiddie, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Russell Bateman replied on Wed, 2014/06/04 - 8:09am

(Hovering didn't work, but I assume it was the brick.)

George Dinwiddie replied on Wed, 2014/06/04 - 10:25am in response to: Russell Bateman

Russell, Yes, the plugin that makes the hover work on the blog posting wasn't carried over to DZone. This joke was my introduction to two-part jokes. I never dreamed it would be so useful later in life. - George

Ingvald Skaug replied on Sat, 2014/06/07 - 7:09am

differences in use and meaning when talking about estimates, and misuse of estimates, is so widespread that i'd argue that the word and concept has become a problem in itself.

apart from that i'm with you in your general thread, and conclusion: it's about understanding, and people and relationships.

if i'm right that "estimates" is lost, that it's started to actually change meaning in the business world, we should try to avoid the use of "estimates".  

George Dinwiddie replied on Sat, 2014/06/07 - 2:03pm in response to: Ingvald Skaug

Ingvald, you'll merely build a wall between yourself and the business world. Avoiding the word is a technical solution to a people problem. That never seems to work out well.

Doug Shelton replied on Sun, 2014/06/08 - 1:00am


These are good analogies and great stories making a valid point of not trying to Forecast precision" in estimates where & when such precision doesn't exist   

But there is a bigger question, regarding estimates I think, that keeps coming up "in the agile world".  

Specifically, I refer to a very recent posting (but supporting much older postings) from well-known XP thought leaderRon Jeffries in the Google Scrum Alliance forum asserting that "we" (I am not clear who "we" encompasses - but later statements in the thread lead me to believe he means other XP [as opposed to Scrum] thought leaders like  Kent Beck)  don't do estimates anymore.  FYI, Ron did clarify later in the same thread that this was **not** a Scrum Alliance stance.  

Specifically (and I cut 'n paste quote), Ron said in response to another poster's question of how to estimate:

Ron Jeffries Jun 6
Re: [Scrum] Re: Story Points: Comparing to the baselineKevin,
On Jun 6, 2014, at 7:04 AM, Kevin Shine <> wrote:
As an online user I want to pay for online goods with my master card so that ........As an online user I want to pay for online goods with my visa card so that ........As an online user I want to pay for online goods with my diners club card so that ........You can agree that the card that gets chosen 1st will be 8 points and all subsequent cards will be 3 points as most of the work will be done on the processing of the 1st card type.So you see leaving everything as 8 is overstating the size. You are aware that most of the work will done on one card. So why have the others as 8? Does not compute.
Long ago, we used to score those things as, e.g., 8/3 meaning that the first one would be an 8, the others 3. Ann Anderson wondered if that was OK and asked Kent Beck. He replied "If you're doing that, you're doing it wrong." I seem to recall that he vanished in a puff of smoke after that but possibly that's just something I saw on TV.Today, we'd estimate all those as 5. ((8+3+3)/3). Except that we no longer recommend estimation of stories.

Ron Jeffries


[bolding and italicizing of statement "Except that we no longer recommend estimation of stories." is mine]

The thread comes from!topic/scrumalliance/Rr91aKrPAd4 .  Ron goes on to detail more about this "no estimates" thought further in the thread:

"I was there when story points were invented. We invented them to be proportional to our time estimates for the stories, which of course we would have assumed to be a linear function of "how hard" the story was thought to be. We wanted points because when we would think "I could do that in a day", we were referring to some kind of perfect day that would never come up in real life. So we wanted to say "one point", meaning "one perfect day".

Most of what you read now in the Scrum literature about points stems from the XP projects where this was done. Unfortunately, XP moved on to something better and the Scrum literature has not yet caught up.

There are many things wrong with all this focus on points and estimates. Some studies show no correlation between number of points and how long it takes to do the thing. No correlation! Whether you use points or estimates, the focus all too easily turns to estimates, and how to do them better. This has absolutely no impact on how long things actually take. Focus on points or estimates makes people think it's bad to go over an estimate (no one ever got in trouble for being done sooner). So focus on points causes people to increase estimates over time so as never to be "wrong". You can do things to push back against this, but you can't fix it."


So - what's my My Point [You ask, George :-]?  I'm curious about this turn of thinking and what other agile thought leaders think of the "No Estimates" approach.  I've been checking with some of them on a one-on-one basis - as you might guess, they don't necessarily agree.  I wonder if this is strictly an XP perspective

What are **your** thoughts on this question? (and why)?

George Dinwiddie replied on Sun, 2014/06/08 - 12:05pm in response to: Doug Shelton

First of all, don't go blindly following "thought leaders." Think for yourself. Ron will tell you the same.

Second, I think you've generalized from "no longer recommend estimation of stories" to "don't do estimates." These are two different things. When teams ask me about estimating stories, I suggest the "abbreviated Fibonacci series," [1, too big]. If they want to use a wider range, though, that's OK. There are usually more pressing problems to address. As they address those other problems, the desire to estimate stories will likely fade.

If you're following Ron, you might notice that he often speaks about the business asking when something will be done, and asking what your response will be. Are you going to tell them Ron said don't estimate?

I think that there are other ways of estimating than breaking all the work down into stories and estimating all the stories. The people saying "no estimates" seem to be fighting that particular approach, but often without looking at the picture around that.

When asked for an estimate, I suggest the first response should be to understand why they want that estimate--what decision depends on it. This conversation can get into murky waters, particularly when there are multiple levels of management involved. But if you don't understand what the people want, then no process is going to help you satisfy them.

I have more thoughts on this subject than will fit into a comment here. I've written around 25,000 words that aren't ready to publish where I'm trying to put those thoughts into an order that will be useful to other people. If you go to, you'll find quite a few blog posts on the topic, not because it's my favorite topic, but because it's one that keeps coming up in conversations. Read some of those to understand my thoughts.

  - George

Doug Shelton replied on Sun, 2014/06/08 - 2:15pm in response to: George Dinwiddie


Thanks for your response.  I'll check out your blog.

Point of Clarification:  actually - I **never** [a word I very seldom use] " - - - go blindly following agile thought leaders" - or anyone else, for that matter.  But what I do like to do is to go to very smart people (and I consider Ron to be one of those as well) and get multiple opinions on such complex topics.  That gives me multiple perspectives to absorb, digest, and contrast. and then, along with my own knowledge and experience, draw conclusions accordingly.

I appreciate your own thoughts on these issues as well.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.