Project Management Estimation

Continuing my discussions about project management, I want to talk about estimations.  We have several meetings to talk about estimations, and several methods to determine estimations.  We task stories with some level of technical details to determine the complexity based on our planning poker estimations.  We guess at hours on how long each tasks takes.  We add up those hours and "plan accordingly" based on those original hours, then adjust when we finish early or run over.  All of that being said,

estimates are guesses, at best.

They are inaccurate and often a waste of time from doing the work itself,  once the work is identified, start working.  You will have a better idea on how long something will take when you are half way done with it.

[caption id="attachment_527" align="aligncenter" width="300"][] The Infamous Cone of Uncertainty[/caption]

For those who aren't familiar with this concept, The top part of the cone is the over-estimate, the bottom part is the under-estimate...  the closer you get to completion the more accurate your estimates will be.  You are 100% accurate on how long something will take after you release it.  (Yes, people need a class and illustration to understand this concept) :-)

"But we can't plan releases if we don't have estimates"

That is true.

Solution:

[caption id="attachment_529" align="aligncenter" width="300"][] Stop Planning Releases[/caption]

When you have completed, note the word COMPLETED, a certain number of stories, branch and release.  You will be 100% accurate with what is being released because it is already done and tested.  You can release at anytime then and you aren't waiting for that last code checkin.  You aren't blocked by this one feature that has to get in.  You release when it is done.  That is a difficult shift for project managers to make.  However, that frees them up to focus on writing better stories and grooming the backlog to keep high priorities high and low ones off the radar.  Estimating is an attempt to hold on to a waterfall methodology in an agile world.  Agile changes, and changes often, so often that estimates are just an old process that gives people a sense of security, although those estimates are often wrong, causing mo estimates to be given and then more time is wasted to defend those estimates when that time could be spent working on the actual work and not discussing on why an estimate is wrong.  I have realized that I can accomplish more work by doing it rather than discussing it.

You must trust your team.

Until that leap happens then you are just micro managing your team.  You need to let that go, along with estimates and then you can above forward produce more and have a solid improving product with real quality and a happy work place.  I think that when you remove the estimates, the meetings that are just to blow up egos, and that trust is prevalent in your team, you will always be leading the industry with innovation rather than chasing it.