How to communicate Hot-fix cost

Ever had problems with the communication between the customer and the development team, due to hot-fixes? Hot-fixes, deliveries that are not part of the planned release cycles are a burden to the entire release process. I personally believe that the cost of the hot-fix isn’t worth it, instead focusing on fixing the bug for the next planned release. Thus not changing the pace of deliveries.

However, sometimes a change of pace in delivery is needed. The pace change can cause severe communication issues between customer and development team, also a part of the increased cost for a hot-fix. But how can this cost be mitigated?

Hot-fix budget

I suggest to have a hot-fix budget, if the customer has immediate problems with a release that has to be fixed outside of the regular delivery pace. Then it is taken from the budget, the budget is communicated cross-team, as a way to illustrate reserved time for bug-fixes. Now you can communicate about the budget.

What happens when the budget limit is reach for the hot-fix?

The current sprint is aborted. There is no point in continuing building software on top of a bugged delivery. The sprint is then restarted when the foundation is stable enough to continue building new features or changes on.