Prioritise scope - don't cut it

In an agile project a lot of effort is spent in managing the scope of a release. But managing scope is not the same as cutting it. Managing scope includes adding and substituting work as well as removing it. Whereas cutting scope is an irreversible activity and hence a form of premature optimisation. (As experienced programmers know well, premature optimisation is the root of much evil.) Scope cutting fails to differentiate between "we don't think that this is important enough to do" and "we don't think that this is important enough to do now", and it promotes a binary view of the project (activities are "in scope" or "not in scope") that doesn't fit with the style of nimble decision making - and remaking - that agile processes allow.
Reflection: Do you keep track of the stories or features that are managed out of a release? Why? Would past scope management affect the planning for future iterations or releases?