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.