This may seem like heresy in the world of "Scrum requires commitments from the team", but think about it.
If your iteration is about two weeks (give or take) and your team is pretty much fixed for that period of time (you can't really "change" a team that fast), then what else is left? Yes, precisely: only scope if left.
In a typical iteration your time is fixed (it better be if you are doing Scrum), your capacity/team is fixed so you are left with only one decision to make: choose to respect either scope or Definition of Done.
Definition of Done is probably the single most important practice as it is the practice that makes sure you have a future, so your choice should be pretty obvious! Don't commit to scope!
It's not that simple, mister!
Of course, the devil is in the details. How can you commit to "anything" for an iteration? Here in lies the crucial point of this post: User Stories are not fixed scope! If you have read anything about User Stories you know of the INVEST properties that each story should respect. The second property is N-Negotiable. This means that even if you commit to deliver the value explicit in the User Story the actual way you deliver that value is to be negotiated with the Product Owner/Customer. This negotiation is the key dynamic for teams that want to succeed at meeting their iteration commitments.
In an iteration you will discuss which are the key User Stories to be delivered. However, later on, when you find out that you are over-budget you should take clear actions, together with the Product Owner, to find out what is the key functionality for each of the remaining stories that should be delivered within the ongoing iteration. And drop the rest!
There's no point in doing over-time and delivering something you will have to throw away later on (because of quality problems or other). Sit down with the product owner and decide what to drop, what to keep in order to deliver the maximum amount of customer value without breaking the most important commitments Schedule and Quality.
Keep your relationship with the product owner as that is the most important relationship for an Agile team.
Photo credit: d_oracle @ Flickr