‘Estimating Session’ is a misnomer

I think the agile community might do itself a favor by renaming these to ‘Understanding Sessions’.

People new to Agile, especially coming from the waterfall/traditional PM role, struggle with the concept of agile estimation sessions.  How can slotting stories into piles of like size be of any benefit?  I need real numbers, not these Fibonacci things!  And then, inevitably, comes the dreaded question; “how many hours is a 5 point story?”.

Let’s think about the advantages of an estimation session.  Sure, we get story points associated to a story, which helps with release and sprint planning, but what’s the real benefit?  Think about how you get to a consensus on a story estimation, it requires discussion on the story sufficient to gain a group understanding, it requires compromise on what the story scope is (which helps further define the story), and it requires all aspects of the completion of the story to be involved (dev, BA’s, QA, deployment, etc).  A successful estimation session ends with the participants gaining further understanding of what is needed.

However, estimation sessions are not planning sessions, and this is where a lot of PM/Waterfall folks get frustrated.  Do we know exactly how we are going to implement this?  Do we have a detailed task list that needs completing?  Do we even have a clear picture yet on how we are going to test this?  No to all.  What we do have is an early agreement on our short term direction based on a ‘slotting’ of these stories into like piles.  It also presents an opportunity for a new team to start to gel around the work they are about to undertake.

I know there are many in the agile community that are starting to question the need for estimations as agile practices continue to mature.  I think they still have an invaluable place as Understanding Sessions, and will remain on my list of preferred practices for the foreseeable future.