No Estimates! Well, Maybe…

A passionate debate about the value of estimates has erupted in the Agile community. Running under the hashtag #noestimates, advocates of ditching estimates and estimating on Agile teams argue that the estimates serve no discernible purpose other than to add overhead to the work of developing product. Even worse, they argue that estimates are overtly damaging to teams, teamwork, performance, and value delivery. Estimates become a weapon in the hands of management, which demands that teams adhere strictly to their estimates regardless of changing circumstances, new knowledge, etc.

I get it. I really do. However, I am still an advocate of estimates and estimating at the team level. Why, you might ask? (Please do!) Well, here’s the thing. Any tool – and make no mistake, estimates are simply a tool – can be misused, abused, or weaponized, but that doesn’t necessarily mean we simply stop using any and all such tools out of fear of their being abused. If that were the case, we wouldn’t have money, credit cards, the Internet, cars, electricity – you get the idea.

So back to #noestimates. I find that, with proper guidance, teams and organizations make excellent use of estimates as a planning tool. Release Planning, Sprint Planning, daily planning, and even portfolio planning all tend to work much better, be more understandable and transparent, when there are team-based estimates backing them up. It is also very clearly the case – in my experience – that teams gain a great deal from the exercise of estimating using a whole-team, consensus-based estimating technique such as affinity estimating or Planning Poker® (a registered trademark of Mountain Goat Software, LLC). And yes, I even like the traditional modified Fibonacci sequence (1,2,3,5,8,13…).

PitchforkManSo when do I come down on the side of #noestimates? The instant the organization, management, or any other force uses the estimates as a stick to beat the team, I am done with estimates. And yes, I have recommended that teams drop the assignment of numeric estimates or any other sizing in that case. I still want the teams to engage in estimating-like discussions of work items for the learning that takes place, but the estimates can go away.

And yes, I have taken my case to management when estimates have become a stick used to beat the teams. And yes, I have been successful in helping management understand that abuse of estimates is a Very Bad Thing and have facilitated a change in behavior. I have also been invited to leave coaching engagements as a result of insisting on the appropriate use of estimates. I thought that was an appropriate instance of applying a Scrum value: Courage.

What is your experience with Agile estimating techniques and the resulting estimates? I’d love to hear from you!

All for now….

…-.-

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….

…-.-