Mike Benner

Estimating has always been a hot bed of contention everywhere I have worked, including my own business.  This has been a hot issue around the office over the last few weeks.  There has been talk of over estimating (aka padding), under estimating and incorrect baselines to name a few of the problems thrown around.  But more important than those "problems",  what is starting the dialogue?

To begin with developers get caught up with the "I burned through more points than you did" mentality.  Depending on how you do your baselines, you can't be competitive with someone on another project.  The least complex story (1 point) and the most complex story (13 points) can be drastically different between a simple online store and a full blown CMS.  So we need to set that competition aside and not worry that I was only able to keep a velocity of 18 points while my team member burned 38 points.

Another reason these discussions begin is caused by acceptance criteria.  The product owner starts adding criteria that makes that 3 point story seem like an 8 point story.  This is where dialogue between you and the Product Owner comes into play.  Remembering that an estimate is just an estimate and is based on the simplest possible solution, what can happen here is scope creep.  Product Owners will sometimes build other stories into their criteria and other times simplest possible is not what they want.  This is not the fault of the estimation, as a matter of fact, it isn't a fault of anything, it is why we adopt an Agile methodology.  The criteria, if large enough and justifiably, can be broken into multiple stories, then do that.  Have estimations done on the new stories and keep that dialogue going with the product owner.

Also, there is the problem of experience and knowledge level.  What may seem complex to you, may be simple for another team member.  But, if you are properly running as a team, that should also make it simple for you when you bring it up at your morning stand up session.  Set some time aside and time box a quick session with a team member to pair with and get that complexity down for you.  Learn how to use that plugin you have never heard of, learn a pattern you have never used or even try that obscure method that is buried in the framework.

Ultimately, remember an estimation is just an estimation and the reason for Agile is to adapt and iterate in quick sprints that will allow for changes, that yes, will sometimes make the original estimate seem off, but what matters is your daily dialogue with the product owner and holding to a true maintainable velocity, even if it is only 9 points a sprint.