Agile Estimating and Planning

I’m continuing to read Mike Cohn’s book, “Agile Estimating and Planning.”  I’d like to get past the halfway mark by week’s end.

In Chapter 6, I liked how he pointed out that three common techniques for estimating are:

  • expert opinion
  • analogy
  • disaggregation (fancy word meaning “to break down into smaller pieces”)

Mike points out that, “Each of these techniques may be used on its own, but the techniques should be combined for best results.”  I agree!

Certainly no one will complain about using expert opinion to make estimates — who wants a non-expert to size work efforts, agile user stories, expenses or revenues?  Expert opinion is bread-and-butter estimation.

Analogy is intriguing, though, because expert opinion might implicitly make analogies when the expert makes an estimate, but very often those analogies never see the light of day.  Agile estimation does make a point of comparing and contrasting one user story with other user stories, but in a traditional project, that may not be so overtly done.

Disaggregation (breaking down into smaller pieces) is what PMI calls “progressively elaborated” estimation.  As you learn more, and as you’re able to see the details more clearly, those smaller details can be sized up, then aggregated to create a larger estimate.

In Chapter 6, Mike introduces Planning Poker and explains why it works:

  • it brings multiple expert opinion together to do the estimating
  • it creates dialog between the experts, and experts have to justify their estimates among other experts
  • like in my Lamborghini Huracan estimation example from last Friday, averaging estimates leads to better results than just selecting single estimates

All this got me thinking:  Why can’t Planning Poker be used for non-agile projects?  Why can’t traditional/waterfall projects use the same kind of estimation approach?  Why can’t a group of developers examine specific coding modules — web pages and web functions, or back-end database procedures — and use Planning Poker to estimate?

The few reasons I can think of why NOT to use Planning Poker for any type of project is that it would cause a cultural shift that some people wouldn’t like, and it would take more time to do the estimation (but, on the upside, more accurate estimates would ensue, and those estimates would be peer-reviewed in a well-functioning team).  But unless the teaming is good, Planning Poker would be a near-fruitless exercise — yet that’s true irrespective of the kind of project methodology that the project team uses.

Leave a Reply

Your email address will not be published. Required fields are marked *