Don’t create a custom set of metrics if you can avoid it. Instead, negotiate scope when possible, and leverage the framework’s built-in mechanisms for evaluating opportunity costs against significant scope changes when necessary.
In Scrum, modest changes in scope must be negotiated between the Product Owner and the Development Team, provided that the changes don’t invalidate the current Sprint Goal. In some limited cases, it’s possible to swap out Sprint Backlog items that don’t impact the Sprint Goal, but this should never be considered a routine “business as usual” approach to such a systemic problem.
Cancelling a Sprint
The canonical approach to a significant change in scope that supercedes the current Sprint Plan or makes the current Sprint Goal obsolete is to cancel the Sprint and return to Sprint Planning.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.
When a Sprint is cancelled, any completed and "Done" Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.
Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint.
Aside from the pragmatic reasons for cancellation, which include the need to replan the iteration, making the cost of interrupting in-progress iterations visible to the organization is essential. The cost of cancellation includes the time, labor, and overhead necessary to rescope and replan, and forces the organization to make smarter business decisions about whether the opportunity cost of the new work is truly worth more than the overhead requires to cancel and replan a Sprint.
Leveraging the Scrum Framework
While there are certainly other metrics you could track, cost/benefit that impacts the project budget directly is generally very persuasive. Furthermore, creating transparency around the impact of replanning on the project’s release plan is also typically more persuasive than trying to measure developer happiness or proxy metrics for quality.
Your mileage may certainly vary, but the framework already provides plenty of opportunity to address this issue within the framework without requiring a custom set of key performance indicators or alternative metrics. Leverage the framework, and only pursue other options when absolutely necessary.