I have never seen this problem solved. The only way, in my opinion, to make this work is to do as little as possible. But firstly, lets see why we need estimation:

The only valid reason for doing this is to give Business an indication of how much the product is going to cost them. Its for an investment decision and of course the variation in estimates has a huge impact on ROI. What makes it tricky is that an estimate is most accurate when there are no unknowns. Practically this is impossible. The more complex the project, the more unknowns there are.

(for tracking purposes I have seen PMs ask developers to break a story into tasks and then provide estimates for that. This is waste, in my experience)

We can’t hold engineering to a number if we don’t provide sufficient details to them.

If we try to pound this problem to submission we might ask Business to spend months in clearly articulating what they need. The costs associated with this is fairly clear. Every day you spend in pushing your product out to market, is a day you waste in earning revenue, a day you allow a competitor to go a step ahead and a day you spend in not changing your mind.

Its not uncommon to have people spend 6 months and more in trying to nail the requirements down. No technology or tool will help you do this better to the extent that you can make this go away.

My experience is that in most projects that I have been, ROI is not really calculated in detail. Most projects start as a Go and then are scrapped midway. This problem is a different one.

Agile with its iterative development tries to solve this in a multi-pronged approach. If we were to break the project into features and then stories, we might be able to provide a relative estimate (points vs hours) at a high-level and elicit sufficient interest to start. As each iteration goes by, the team’s velocity is measured and can be used to project dates when features can be released.

Business can prioritize features and stories so that they get the biggest bang for their buck. Business can also freely change their minds.

With an experienced, talented, sincere team in place (all three are requirements for agile to work) its a fair assumption that velocity will go up, and that the team will do their best. With the teams I have worked on, the meaning of doing their best is really taking on more work mid-sprint even if they pass their historic velocity numbers. “We need more stories” is beautiful to listen to. You do that a few times and velocity is no longer that important as a metric. Maybe it is for releases, but most definitely not to showcase your excellence.

In terms of effort spent into estimating, you really dont want 7 developers 2 hours every 2 weeks. Thats $3000 at $200 an hour. If you remember that an estimate is not held against a developer, maybe even a couple of them can run through this list on behalf of others.

I am aware of the many reasons for making it more rigorous. I have tried that and I don’t think its worth the effort. I might change my mind, but till then, let me enjoy some lightweight estimation.

In short:

1. Keep it simple (no multipliers) and high-level
2. Like there is no perfect story, there is no perfect estimate
3. An estimate is best used to figure out when the features will release
4. An experienced, talented, sincere team will quell any fears of underwork
5. Historical velocity is the best indicator of future velocity