The Estimation Game

The project managers high-wire act of balancing scope, schedule and cost is predicated on accurate estimates, and who hasn’t been burned by that?   It’s not uncommon to find teams where estimating techniques seem to have been learned at Hogwarts: The Bedazzling Hex, used to conceal a person or object, The Bubble Head Charm, which enables one to continue to breath in the presence of a proposal that really stinks.  Then there’s The Confundus Charm, which causes the victim to become confused, befuddled and prone to agree with estimates that are well shy of the mark.  And then there’s the ubiquitous use of The Obliviate Charm, whereby team members seem to lose memory of practices previously proven to be painful.

Of course there are teams that have a history of being pretty accurate without magic charms, but without begin able to tell you much about how.  Often it turns out that their success in estimation is based on intimate familiarity of the problem domain by one or more of the team members.  Sometimes this is fine to run with this “heroic individual” model, but often it is just a matter of time till the team composition changes, with the work flow continuing until one day the project manager finds herself facing an array of commitments, budget burned.  You’re vulnerable to the extent that you lack an organizational culture with a knowable, learnable process for estimation, just as you strive for with code quality, test coverage or devops.

Our purpose here is not layout any prescriptive approach to estimation, but to provide context to understand what we’re really trying to accomplish in estimation, and to explore some approaches that might help in your situation.   We’ll look at how to avoid fuzzy mismatched estimating abstractions that have a way of ending up as house-on-fire projects.  We’ll talk about self-calibration exercise aimed at tempering perennial over-optimism.  We’ll talk about applying the definition of done to the estimate.  We’ll look at techniques of specifying acceptance criteria as part of the estimation process, and we’ll pay a visit to shangra-la where not estimating at all can be a great place to be.

Regardless of experience level, if you are a developer, on the QA team, an analyst, a project manager or a product owner, hopefully you'll come out of this session with a better sense of how get a handle on software estimation.