I find it painful how many Scrum Teams see the Sprint Backlog, notably their selected Product Backlog Items as their commitment. And then commitment is perceived as ‘signed with blood’.
This often leads to issues like:
The Sprint ‘fails’ when one or more items aren’t finalized.
Stress levels go up towards the end of the Sprint. People are working overtime to finish the items.
New items that -due to additional insights- are considered to be more important than those that were planned at the Sprint Planning will not be picked up.
Items that are no longer relevant are not being dropped because these items are part of the commitment.
The Sprint succeeds when all items are delivered, regardless of the fact that these items may have become irrelevant due to new insights.
The Sprint Goal is made irrelevant. The only thing that counts is delivering all the items.
People might find all of the above normal for Scrum. It isn’t. The Sprint Backlog is not set in stone. The team works towards meeting the Sprint Goal, not towards delivering all items as planned. This is a subtle difference. You may meet the Sprint Goal while you change the Sprint Backlog.
In complex environments, you may know WHAT you wish to achieve, but not exactly HOW. The Sprint Goal is the WHAT. This is what the Developers commit to achieving. The selection of Sprint Backlog Items and the plan is the HOW. These can change due to new insights.