Can't believe nobody pointed this out yet: Estimation is NOT commitment. Committing to estimates paves your road with good intentions (and leads to hell). Don'

Can't believe nobody pointed this out yet: Estimation is NOT commitment. Committing to estimates paves your road with good intentions (and leads to hell). Don't commit to estimates!! Estimation is EXTREMELY valuable to help the business get a sense of engineering capacity. You can't tell the business, "we can't launch a Facebook competitor in a week of effort." No shit, Sherlock. So what can engineering work on next? What can the business ask engineering to prioritize, that's chopped up into a small enough piece that it can work it's way through development and into production in a more or less predictable manner, while still being large enough to have demonstrable business value? Orgs that can't produce reliable software estimates suffer from one of the following: unreliable infrastructure (can't deliver new builds if your build system is down), insurmountable technical debt (can't reliably and quickly roll out requested changes if you don't have automated integration testing), bus factor 1 (look who decided would be a great week to be in a car accident! /sarcasm), lack of senior technical leadership involved in planning / chopping up tasks. I hate to break it to people, but those are all pretty much fixable. You can have highly-available tooling. You can have competent technical leadership that balances technical debt and creates clear task work for engineers. You can have team leadership that prioritizes getting information out of team member heads and into source code or wiki (when appropriate), and cross-training. The fact that most organizations fail at best practice does not mean that best practice is inaccessible.