DevOps Zone is brought to you in partnership with:

Esther Derby helps create great work places where people can do their best work and make products their customers value. Not so very long ago, she made her living writing code. She's co-author of Behind Closed Doors Secrets of Great Management and Agile Retrospectives: Making Good Teams Great. You can read more of her thoughts on management, organization, teams, and agile methods at www.estherderby.com Esther is a DZone MVB and is not an employee of DZone and has posted 73 posts at DZone. You can read more from them at their website. View Full User Profile

Estimating Is Often Helpful. Estimates Often Aren't.

08.08.2012
| 10643 views |
  • submit to reddit

Recently I tweeted, “/Estimating/ is often helpful. /Estimates/ are often not.”

Several people asked, “How can this be?” Let me say more, in more than 140 characters.

/Estimating/ is often helpful.

Estimating helps when the process of estimating builds shared understanding among the people who want the work done and the people doing the work.

Collaborative estimating gives the best results. Diverse experience yields a broader range of perspectives and questions.  Questions and perspectives build understanding of the what?, why?, and who? that is related to a request. That’s helpful.

Group estimating reveals differences in knowledge and understanding. Finding those gaps early is helpful.

Group estimating surfaces assumptions. When we are aware of our assumptions, we can verify—or debunk—them.

When the group knows enough about the “what” to think about the “how,” they can analyze implementation.  Working out implementation details reveals more assumptions, and generates more questions.

Sometimes estimating reveals that you only know enough to reason by analogy. The best you can do is posit that the desired functionality is about the same size as some X.

But sometimes, estimators realize that they don’t know enough to think about size or effort in a meaningful way.

This situation calls for discipline—discipline to resist guessing and speculation. Estimates born of baseless, ungrounded guesses are worse than useless. Rather than guess, in order to gain great clarity about needs and context it's best to troubleshoot via experiments, interviews, models, sketches, or some other helpful activity. Then try estimating again.

/Estimates/ are often not helpful.

People turn estimates into targets. Meeting the target becomes the de facto goal and the de facto method. The need of a meeting ends up fading as a priority.

People can construe estimates as promises. No one can predict the future, but many people treat estimates as guarantees. Failed predictions may fan blame. Under the worst circumstances, trust and openness cause suffering.

People might construe estimates as bids. Bidding usually involves some calculation of profit. That implies a margin. However, managers discourage margins in estimates. Managers view “padding” as a moral failing–but it’s really a contingency for the unknown (Or compensation for bosses who are known to cut estimates to fit wishes. See below.).

Inappropriate precision in estimates implies that people know more than they do.  When expectations and reality meet, people may feel disappointed. More likely, they feel deceived. Trust and openness cause suffering once again.

People game estimates. How many of you developers have thought long and hard about an estimate, only to have a manager say, “Estimate X is too high. It should be between A and B.”  I, too, have been this way. Fudging estimates to fit wishes sets off another round of deceit and disappointed expectations. Trust and openness become scarce.

So please, estimate. But don’t get caught up in estimates.

Published at DZone with permission of Esther Derby , 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.)

Tags: