What I've often experienced is the manager estimates what he wants to happen (typically fairly arbitrary or based on company goals) then the team kills themselv

What I've often experienced is the manager estimates what he wants to happen (typically fairly arbitrary or based on company goals) then the team kills themselves trying to accomplish the timeline because they don't like to fail. This is great for short term productivity but long term leads to attrition and spitefulness from the team. I'm not saying it's not possible, but make sure what you think is happening, is happening (good sustainable estimates vs. constant crunch time estimates). Of course, situations warrant crunch time, but I've seen departments in a constant state of crunch just by the nature of their sprints. The saying goes, you can't sprint a marathon. 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.