A little over a week ago, Paul Boos hosted the first Agile Dialogs Unconference. Our subject was inspired by the debate surrounding #NoEstimates. We hoped to get beyond some of the rhetoric and grapple with perspectives from both sides. I was hopeful that we would increase our overall understanding and generate some ideas for real improvements we could use with our teams. I think we achieved that goal.

A number of good ideas came out, and Paul has generated an accurate list. For me, there were three main lessons. The first is that when we debate #NoEstimates or #YesEstimates, we’re often talking about very different things. We paused several times in our discussions to ask ourselves what we really mean by “estimates.” There were some very diverse perspectives and we often needed to recalibrate. Differences in the definition of “estimates” influence how we approach the idea of #NoEstimates and what we think it means. Many of the arguments on Twitter seem to have their origin in these kinds of misunderstandings.

We were able to get past that in our dialog and draw out some valuable perspectives from both sides. From the #NoEstimates side, I think one of the most important lessons is that when we make an estimate—regardless of whether or not that is a traditional time estimate or one involving something more abstract like story points—we risk anchoring ourselves to a particular implementation approach. This may be fine.

But there are cases where it will lead us down an undesirable path and trigger rework or introduce technical debt. It can be difficult to avoid, as we often don’t realize the impacts of our assumptions until we have a chance to test them. Usually, that comes long after an estimate has been made. Teams that make estimates might want to keep this in mind.

Critics of #NoEstimates point out that estimates are often blamed for broader organizational dysfunctions. We discussed this at length and cited a number of examples from our own experience. Although estimates are a visible aspect of dysfunction (like when they’re used to transfer risk), that does not mean they are the cause. They may only be a surface symptom; discarding estimates may have no effect on these deeper issues and may only further complicate the problem. If you’re looking to discard estimates, you may want to investigate whether or not this applies to your environment.

As with many things, the benefit or harm of estimates appears to be very much dependent on context. By getting together and sharing our experiences, we helped broaden our perspectives and gain more understanding. I’m looking forward to more Agile Dialogs.