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:
1. 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.
2. Estimating enhances understanding of the work
We cannot, as a Team, pull in 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.
3. 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 Backlog Refinement session, which is where I like to get the Story estimates done, is a Product Owner with a stack of new Stories to prioritize.
4. Estimating helps us become a Team
Collective, collaborative, consensus-based estimating — and I really like affinity grouping as the mechanism — helps us learn to listen to and understand our teammates. Affinity grouping helps ensure that even the shy, quiet, oppressed, or disengaged Team Members take part in the discussion. The rules of affinity grouping, 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? They are clearly useful to the Product Owner when planning a release or managing stakeholder expectations. Perhaps they are useful to the Team in Sprint Planning. Either way, it’s the activity of estimating that matters most.
Looking for tips on better estimating?
We’ve got training for that.
As Always, Stay Agile.