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.

At Integrum one of our policies is a very open accountability.  Whether it being calling some one out on being late to stand up, not running tests in their project or just calling bullshit on an excuse, anything goes.  At first I was kind of blown away at this method, conversations I felt should be handled one on one and in private, were happening in front of the team and it was quite a shock to the system.  Then I witnessed a gigantic burn down chart for the day, placed in the center of the room and a developer sitting in front of it updating over its 6 hour range.  Yes, this was an extreme example and all done in fun, but you know what, it worked.

But it doesn't always work.  Some people will let it just roll off their backs and repeat the same behavior day after day, while others immediately get defensive and are too busy thinking of how to respond, deflect and excuse the problem to actually learn and adjust.  The latter of the group, don't realize they are not "getting in trouble", but are being helped and by it being an open forum everyone can typically glean some knowledge from the discussion.

For me personally, nothing beats the open accountability method.  Call me out, make me aware of something I may not even be aware I am doing.  However, with the wrong team members, typically people that aren't self motivated and don't strive to be better, this system only breaks down into public arguments and can actually make for an uncomfortable work environment and limit productivity.  

While I highly recommend this method, make sure you are staffed with the right group of people.  People that want to be better.  People that want to make their team members better.  Odds are if you have assembled a team that contains these like minded individuals, they will have already started this methodology and will embrace your companies official shift to Open Accountability.  When things start clicking prepare to see individual growth increase and team growth explode.