Also, depending on the organization, a 20% buffer seems on the low side. If you can guarantee zero distractions throughout the day, outside of 1 or two meetings a week, 20% is probably ok.
FWIW, if the developer makes the estimate, he is more likely to live up to it, because it's not just some number someone pulled out of their ass. I'm not saying that's you, I'm just saying how I've seen it happen time and time again. I like to think I give good estimates, but like you said, it's a negotiation and if a dev says it will take longer, it will take longer. They most likely know the codebase way better than some manager does.
I contest this. This assumes the manager is also some sort of software engineer plus I don't understand why would there be any negotiation: a project asks for an estimate and we give it based on how much we feel it's going to take, there is no negotiation; either the project manager accepts it or reduces scope and we make a new estimate, my manager is uninvolved.
I suspect this might be a work culture thing: in my country managers aren't timekeepers, their responsibility is making sure we have all the conditions we need to be productive and be "invisible" otherwise.
> This assumes the manager is also some sort of software engineer plus I don't understand why would there be any negotiation:
We have whole methodologies based on the premise that we (software engineers or managers) are incredibly horrible at estimating software.
With my team(s) I (almost) always knew (more or less) the time for various tasks.
I was also expecting any feedback/'negotiation' to happen at the time of task assignment OR as soon as someone can see that deadline is at risk.
I know that Tasks from Tasks vary, but hey, this setup requires knowledge from both parties AND trust.