I’ve been writing about estimating and planning a lot lately, so this is worth sharing:
Numbers are not the goal. Successful outcomes are.
Those footing the bill would rather have a successful outcome than an excuse to blame the estimator. In exploring better estimation, I’m not looking to protect the estimator or development organization from censure or litigation after a disappointment. Instead, we use estimation to help guide the project to success from the point of view of both those paying for development and those performing it.
— George Dinwiddie, Software Estimation Without Guessing
When I’m feeling lousy about an estimate, it’s usually because I’m treating it like a promise instead of what it actually is: a piece of the puzzle for deciding what to do next.
The tricky bit is setting expectations up front: this estimate is based on what we know today, not what we’ll discover tomorrow. Everyone knows surprises will happen. The estimate should help the team make better decisions when they do, not box them into promises they can’t keep.
The best estimates I’ve given weren’t the most accurate—they were the ones that helped teams navigate uncertainty instead of pretending it away.