Strategic scope management - discussion

In agile projects, scope is treated as "not fixed", i.e. whenever your project gets in trouble, you're supposed to cut scope (features, user stories) instead of increasing the budget or delaying the release. So managing scope should be pretty important, right? Yet from the point of view of, say, a Scrum team, it might look like this: "Scope is whatever the Product Owner wants us to deliver in this sprint. We don't look further into the future, we don't guess what might be next -- we're agile.". (I'm exaggerating) Let's have a discussion around these questions: - What is good strategic scope management? - Who should manage scope that crosses team and product / service boundaries? - Who should decide whether to turn an idea into a project? How? - How can you structure scope in a meaningful way? - What do stakeholders want in terms of scope? - Who get's to decide about "make or buy" for projects, or features? - For good scope management, is it enough to know about the structure of business value? Or should you take architecture / implementation into account? We have a few opinions about these, but we'd very much like to hear about your experience. We can also report on our own experience in several large projects.