Ghosts, Ghouls, and Estimations

Lurking behind the ominous shadows is something so scary that the shadows cringe in fear.  The mere mention of it sends people running and screaming as they trip over each other in their best efforts to get away.
If  you are one to get scared easily, I recommend you stop here because this is a word that sends chills down spines, makes people cower, automatically arches cats' backs in a defense stance.  The word is:

             Estimation

_________________________________________________________________________________

Estimating within an Agile project is an easy thing to do, but one of the hardest concepts to grasp.  We just don't get it.  If using points, we want to try to correlate points to days.  If using ideal days, we want to use that to understand why something we said would take "two days" really took three or four.



We forget that when estimating any type of project, using any type of estimating methods, estimations are just that; estimations.  They are arbitrary numbers or days or sizes that are meant to give us a sense of how much we can get done.

A big topic of discussion with teams I coach, and other coaches I talk to, deals with having experienced people estimate with those not as experienced.  For instance, the Lead Engineer will decide how much the engineer can do.  Using the Fibonacci sequence, The engineer says that the work is a 8, but the Lead says that the work is a 5.  Thus, what gets put into the story is the 5.  This happens in reverse also.  The lead may tell the engineer that they aren't understanding the story and the effort is actually 13.

This may  not seem like a big deal until the burn down charts begin to show that the engineer is not meeting what was planned (or is doing much more work than what was planned depending on the scenario).  Estimations are meant for the person/people working on those stories, not for people outside the team who are not involved.  In cases where the Leads or a SME want to be involved, do so by involving them in the conversations about 'what' needs to be done to get the story done.  There can be some 'how' discussions, but there should not be any discussion from them regarding 'how much time or effort' it will take.

Let's say there is a project to build an origami army of a swan, plane, flower, and frog.

The complexity of building each is different depending on who is doing the building.  For instance, I'm really good at building a swan because I had to do 200 of them for a class project once.  However, for me to build a plane would be a disaster, and if the requirements were that it flew, it would be an even bigger disaster.

Now, you may know how to build a plane so well and so efficiently that it is the easiest thing to do.  If you told me that the plane was easiest for me, that would be an inaccurate assessment and estimate.

                 

 vs 


TIPS:

• Have the people doing the work do the estimations.  Only they know what they can do.

• No need to worry if you think the estimations are off.  Each iteration, we can review the estimations and adjust for future iterations.

• A velocity chart with estimated vs actual can show you gaps over time so that we can adjust.

• Estimating forces us to think differently by making estimates relative and arbitrary.  Be cautious not to relate point estimates to the amount of days it took to complete it.