Recently, I tweeted, “Estimating is often helpful. Estimates are often not.” Several people asked, “How can this be?” Let me say more about agile estimation, 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. This is especially helpful when looking to strengthen or build a team.
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 related to the request. That’s helpful.
Group estimating reveals differences in knowledge and understanding. Finding those gaps early is helpful, and team communication is better as a result.
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 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 X.
But sometimes, agile estimation helps teams realize that they don’t know enough to think about size or effort in any meaningful way.
This situation calls for discipline. Discipline to resist guessing and speculation. Estimates born of ungrounded guesses are worse than useless. Rather than guess, experiment, interview, model, sketch designs or do some activity to gain more clarity about needs and context. Then try estimating again.
Estimates are often not helpful.
Agile estimation is not without its downsides. People turn estimates into targets. Meeting the target becomes the de facto goal and the de facto method. Non-value added but necessary work gets pushed aside. Meeting needs fades in priority.
People construe estimates as promises. No one can predict the future, but many people treat estimates as guarantees. Failed predictions fan blame. Trust and openness suffer.
People 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 suffer.
People game estimates. How many of you developers out there have thought long and hard about an estimate, only to have a managers say, “That estimate X is too high. The estimate should be X – Y.” Me, too. Fudging estimates to fit wishes sets off another round of deceit and disappointed expectations. Trust and openness suffer.
So please, estimate. But don’t get caught up in estimates.