I'm not sure why you feel the need to falsely frame the point as a request for a blank check. I get all the reasons you provided, but at the end of the day an

I'm not sure why you feel the need to falsely frame the point as a request for a blank check. I get all the reasons you provided, but at the end of the day an honest discussion needs to ask is estimating tasks effective. Do developers get more done or less done when estimating tasks vs not estimating tasks? The only claim estimates would increase productivity is the extent they are deadlines. But I think you will see that when developers take meeting their estimates seriously their estimates tend to get more conservative. And then there can be a desire to not over deliver on the estimates to lend those estimates legitimacy. Without estimates, you still have a performance metric to use, individual velocity. If one developer isn't getting stuff done as fast as others, you don't need estimates to know they aren't performing as you would like. Are estimates reliable? This of course varies greatly by the project and the team but I my experience estimates are typically no more precise than 50% of their length. So a 6 month project probably shouldnt take longer than 9 months. Your mileage may vary, but is there a way to crudely estimate a project without asking for estimates? I would say probably. Why not just measure the teams velocity and project it? I would argue estimates were a first guess at a way to run a development team which has survived mostly because of a refusal to consider the first guess might not have been the best guess.