It's the Estimating that Matters, not the Estimates

It seems like there is always some sort of controversy or at least discussion swirling around the merits of estimating user stories and tasks. Mike Cohn's justifiably famous book, Agile Estimating and Planning, makes the case for relative (story point) estimates for user stories and hours for tasks. I have always found his ideas useful and recommend them when coaching new teams. As many agile practitioners have pointed out, that level of estimating tends not to be necessary for mature teams. Some even think estimating isn't necessary at all.

I think the discussion of whether agile teams need to produce estimates -- particularly at the user story level -- or not misses the point. For me, particularly with newly formed teams, it's the act of estimating that is absolutely vital; the estimates produced are potentially useful, but the estimates are not the point; it's the estimating that matters.

Teams new to agile or teams that are re-forming with new members who lack deep agile experience need to engage in estimating for a variety of reasons:

• Agile teamwork is different! Most of us who have spent the majority of our working lives digging around in code or other parts of software or high-tech projects never had the luxury of providing our own estimates. We have traditionally been told what needed to be done and when it needed to be done. End of discussion. Team estimating helps bring to life the reality that working in an agile environment, on a Scrum team, really is dramatically different than anything else most of us have ever experienced. We are authorized to estimate our collective work and our estimates will be honored by the Product Owner and the rest of the organization. That is a substantive demonstration that no amount of happy talk can supplant.
• Estimating enhances understanding of the work! We cannot, as a team, commit to any work that we don't fully understand. Again, in sharp contrast to the bad old ways of working, Scrum team members are never compelled to take on or commit to work that is unclear or ill-defined. Team estimating provides a context to tear into the work -- the user stories the Product Owner thinks are coming up soon -- and really understand the details. The estimating part is important because it requires us, as a team, to agree on an estimate of effort, complexity, and risk for each user story. The discussions must be focused and grounded in reality, not vague, open-ended, or facile.
• Estimating helps us discover gaps in the work. As we engage in serious discussion about each user story, we collectively begin to see the connections between the stories and the disconnects that indicate gaps in the backlog. One of the most satisfying outcomes of a Story Time meeting, which is where I like to get the story estimates done, is a Product Owner with a stack of new stories to prioritize.
• Estimating helps us become a team! Collective estimating -- and I really like Planning Poker as a mechanism -- helps us learn to listen to and understand our teammates. Planning Poker ensures that even the shy, quiet, oppressed, or disengaged team members take part in the discussion. Odds are everyone on the team will be high or low estimator at least a couple of times during an estimating session. The rules of the game, when observed rigorously, ensure that everyone must listen to the person speaking and more than that, must take seriously what that person says. Again, the deliverable of an estimate compels everyone on the team to take the discussions seriously.
  

So what about the estimates? Perhaps they are useful to the Product Owner in Release Planning. Perhaps they are useful to the team in Sprint Planning. Perhaps, as many practitioners suggest, the estimates really are not useful in those contexts. I don't necessarily agree, but I'm fine with that opinion. It's the estimating that matters, after all!

All for now....

...-.-