In defence of cutting scope
Scope cutters can get a bad rap. We've all experienced situations where a team, under the pressure of a looming deadline, is forced to remove functionality from their upcoming delivery and the result is an unworkable feature that does not meet user needs. So, it's understandable that when the scope of a feature is cut during the development cycle, this is often met with cynacism and disappointment.
It doesn't always have to go this way, though. When trimming scope, teams should keep in mind the intended outcomes of their initiative, which should've been explicitly set before execution began. If the particular reduction they're tempted to ratify significantly reduces the likelihood of achieving intended outcomes, teams are probably better off simply taking more time to finish their work.
This goes the other way, too! Teams should be encouraged to safely reduce scope, even when they're not pressed for time, in cases where desired outcomes are not at risk. Less complexity will lead to shorter cycle times and make delivery more straight forward. And, by getting a slimmer implementation out into the wild first, teams may realise they never needed the heftier scope to begin with. Over multiple iterations, this will lead to more frequent delivery of value and greater ROI.