Then, two weeks later, being asked why I did not complete what I committed to.
"Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint."
https://scrumguides.org/revisions.html, "Changes between 2010 and 2011 Scrum Guides"
I say this as someone just moving into project planning and management. From that perspective you start to see that some level of estimation s critical. My preference is to ask devs for just the tightest bounds to timeframe they're actually comfortable with, then estimate based on that and pass up the chain. I consider it to be on my shoulders if things take longer than I communicated upwards.
Anecdotally this has worked out remarkably well throughout my career - from single dev to cto - even stuff that I _new_ was going to take for example 2 days, if done properly ended up in like 5.
Didn’t matter if I was doing the estimate or someone else. At some point I just gave up and started doing the “my gut says 3 hours, so it must be 7 hours of work then, and send that up the chain. That cheeky “+1” had saved my ass more times than I can count.
But without the feedback of actually having done the work, any estimate is bound to be wrong.
I made exactly this suggestion and was laughed out of the room.
Granted this was for large and small estimates, but I still don't think it's the worst idea.