Voluntary over commitment

A pitfall could be you might not be adhering to the "Sustainable Pace". In other words, people in the team might be burning more energy than they can on the long run. you might be unknowingly be burning them down (or they are burning down themselves)

With regards to your velocity charts: it is a metric to help you plan, and which might help to visualize tema improvements. it is not a promiso for future work nor is it an argument for performance. be very careful how this metric is used, where it is used for, and who uses it.

With regards to your promise: adding a stretch story to the sprint is not the same as making a promise. The team commits to the Sprint Goal, that commitment might be seen as a "promise" in a way. But adding a stretch sory is not the same.

I think that's great that the team has the commitment to take on some additional work after meeting their primary goal.

Given that this work is usually a stretch goal which may not be completed in the Sprint do you think the items they're choosing to focus on provide the most value? It could be a good opportunity for them to explore some PBI's that would improve their ability to innovate or time to market such as technical debt, automated testing, continuous integration, etc. 

The velocity chart will not look good (it will show X committed but Y delivered for several sprints) - but I might be able to talk around this when it goes in front of stakeholders

Why would there ever be a need to discuss a team's velocity with stakeholders?

On another note, I am personally not in favor of a team adding a "stretch" story (or stories) to a sprint, for the reasons stated already (makes a sustainable pace more challenging, reduces transparency around the actual forecast), but also because it adds lean waste to the sprint.   The Lean Waste is in the form of talking about item(s) that may not be delivered in a sprint, and carrying items from sprint to sprint due to unfinished work.

It is a much more preferable (and cleaner) approach to "pull" item(s) into a sprint as extra capacity allows, than overloadiing a sprint at the start.

• The velocity chart will not look good (it will show X committed but Y delivered for several sprints) - but I might be able to talk around this when it goes in front of stakeholders
• We're potentially promising to deliver something on a certain date, and then we don't deliver it. e.g.  dependencies for another team - but I guess as long as we communicate its a stretch, no one should rely on this.

What is X, if it is not the Sprint Goal? Why would this so-called "stretch story" represent a commitment at all?

To add onto what Ian asked, the Sprint Goal outlines what should and should not be in the Sprint and helps align the team on what the expected Sprint Review demo would focus on. The commit is on the Sprint Goal and not the individual stories. What kind of work do you consider to be the over commit? Is it tied to and required for the Sprint Goal?

The velocity really should help you gauge if there is just enough work for the sprint based on the Sprint Goal. If there is too much, then adjust the Sprint Goal appropriately. At the Sprint Review, you focus on the delivery of the Sprint Goal. The velocity is completely irrelevant. Teams don't deliver output, if that makes sense. That metric is just a Sprint planning tool used to help you start the conversation about capacity.

Based on the example above about X and Y, it will be helpful if the team understands why they they did not complete or reach the committed items and how they can adjust or adapt or improve on it.