The only time I perform maintenance is when I'm adding a new feature. Before I add any new code I'll inspect the code that will be touched by the new code. If it's hard to understand or the abstractions are a bit wonky for what I want to add then I'll spend some time refactoring it. In this way your maintenance work is always done while delivering observable value to the business. You don't need to provide any justification for it. If it means you're going to take a bit longer to deliver a feature than expected you can just tell your boss that the code wasn't in the state that you expected when you gave an estimate. If you wrote the code in the first place it's fine as well. You can just say that the priority at the time was to get the feature out fast so there wasn't time to shine it up.