A senior manager in a large client recently confirmed to their product department and dev team leads, the value of estimating new software tasks (enhancements and new features), citing that estimates allow the Product Owner (who understands the value of each item) to perform a basic cost-benefit analysis, and perform a go/no-go analysis.
This led me to explore the value of estimating, and familiarize myself with the #noestimate movement. The fans of #noestimates, believe that since estimates are inherently incorrect there is no value and they should be ignored, and in some cases can be downright harmful.
Given the complex nature of software development (more on this in a later blog post), I absolutely agree that estimates are inherently incorrect – that’s just reality. This doesn’t mean, however, that estimates should be thrown out with the bath water.
To paraphrase Dwight D. Eisenhower “Estimates are worthless, estimating is valuable”.
Whilst estimates are likely to be wrong, the value is in the estimating process. Having a team of developers look at the same requirement, provide a private estimate and then publicly discuss the estimates (a la the Wideband Delphi technique) is worth gold.
In general I ask the highest and lowest estimators to share their insights – getting a peek into the rationale used when they chose this score, and the subsequent discussions amongst the group is priceless. Sometimes I request the team to re-vote; often it’s possible to ‘read the room’ and agree verbally on the best score.
At the end of the day, the discussion around the estimates leads to a richer understanding by the team of each requirement.
That’s why I’ll continue to encourage estimating – and actively downplay the estimate in isolation.
What are your thoughts?