How estimation is marketed matters, too. Don't let your stakeholders think of it as an over-estimate. It's an estimate that considers the needs of the full software development lifecycle: automating tests, developing monitoring, refactoring to clean up old tech debt, etc.
Makes sense. It also must be nice to convey the dev lifecycle factors that go in to estimates.
Where I work refactoring is a trigger word and we are advised to never say the word when talking to management and it must never show up in any planning material/meetings etc.
Someone made the mistake of including refactoring efforts in their plans and they were asked to scrub it out.
This all boils down to how much you trust your management with the long-term health of the business. Not refactoring may actually be the right call. Maybe it will become a necessity later, maybe not.
If management just wants to flex their authority, you can inflate your initial estimates. It's only unfair when one side treats an estimate as a negotiation and the other side doesn't.
