Developers have no love of estimates. They’ve been pinned in a corner by an estimate and beaten to a pulp. “But you said it would be done by Friday!”
I don’t have any problem with a developer being reluctant to give an estimate. I do have a problem with developers refusing to give estimates unless they have everything nailed down in a nice spec document and they’ve completed their design.
You can’t know everything when you give an estimate, hence the term. You base your estimate on breaking down the work you think will need to be done into small enough tasks and then build from there. You take into account risks and any historical information you have. Then you give an estimate.
The business has a right to expect this. In no way does this mean the estimate will play out exactly. If it does, likely it was an overestimate and the developer simply backed into it. Estimates will get adjusted by reality. As you get more information you can update estimates and give better future estimates. Scrum builds this into the process as you change your estimates every day. The important point is how many hours you have left on a task or whether you finished it, not whether the actual time you spent on a task lined up with your original estimate.