zlacker

>>mattjh+(OP)
After owning a product, I've developed a lot of sympathy for the people outside of engineering who have to put up with us. Engineers love to push back on estimates, believing that "when it's done" is somehow acceptable for the rest of the business to function. In a functioning org, there are lot of professionals depending on correct estimation to do their job.

For us, an accurate delivery date on a 6 month project was mandatory. CX needed it so they could start onboarding high priority customers. Marketing needed it so they could plan advertising collateral and make promises at conventions. Product needed it to understand what the Q3 roadmap should contain. Sales needed it to close deals. I was fortunate to work in a business where I respected the heads of these departments, which believe it or not, should be the norm.

The challenge wasn't estimation - it's quite doable to break a large project down into a series of sprints (basically a sprint / waterfall hybrid). Delays usually came from unexpected sources, like reacting to a must have interruption or critical bugs. Those you cannot estimate for, but you can collaborate on a solution. Trim features, push date, bring in extra help, or crunch. Whatever the decision, making sure to work with the other departments as colaborators was always beneficial.

>>notjus+xw
This is true, but the problem is that engineers are being asked to over-extrapolate given the evidence, and expected to own that extrapolation despite the paucity of evidence to make a good estimate.

I *HATE* estimating roadmaps, because it feels unfair. I'm happy to estimate a sprint.

>>Curiou+XE
It's definitely unfair in a sense. But companies that make over-extrapolated roadmap estimates from not enough evidence systematically outcompete those who don't, because their customers greatly prefer companies who give a date and then try their best to hit it over companies who say they don't know when the product will be ready for X and you'll just have to wait and see.