When planning a single user story in a software project it’s pretty common for someone to sit down and think about some details of how it should be done. There may be some wireframes, some reference to the code that needs changing, and of course a good definition of “done”. This helps us confirm to each other we’re thinking about the same thing. It also helps us estimate the effort.

This is straightforward. Still, I find it continuously curious that it also works the other way round: estimating a card helps us work out the details. There have been many, many times I’ve seen this in planning poker—everyone makes an estimate at the same time, and then we discuss discrepencies. “Why do you two think it’s an 8 when others think it’s a 5? What do you think we’ve missed?” A conversation ensues, inevitably surfacing details that weren’t mentioned until now.

How does this phenomenon work? I think it’s because estimating forces us to look at the work in a particular way—a new way. It creates a new lens with which to view it. Presumably there are other questions which might also reveal further details, though I can’t think of many. No doubt “What are the edge cases we’ll need to test?” would reveal more, but that isn’t as neat as a single-number answer we get for estimation.

In any event, the next time someone asks me “Why do we bother estimating?” I’m going to cite the value of a simple question that can provoke unexpected insight.

Photo by charlene trapp