Sprint Planning: Forecasting vs Committing

I came across an interesting discussion of the topic above:

In the summer of 2011, Ken Schwaber and Jeff Sutherland revised their Scrum Guide. In it, they removed one long established behavior known to Scrum, which is the commitment the team makes to the product owner and the customers. Commitment was replaced by forecast. They say that teams may forecast their work, but not commit to it.

The Author — Mitch Lacey addressed his opinion I extracted from the article as following:

While I understand their logic, I prefer commitment for the following reasons:

• Committing to something puts the team in a different mindset than just forecasting. If a team forecasts, it is implied that not meeting everything they said they could do is an acceptable behavior. While teams may learn from their forecasts, eventually having less estimation variance, I find that teams that forecast take longer to reduce the variance as compared to teams that commit.
• Forecasting, or estimating, is appropriate for the product backlog. However, when teams move stories from the product backlog to the sprint backlog and break them down, they are adding another level of granularity, finding out small details that allow them to ask themselves “can we commit to this?” Forecasting runs the risk of falling back to a lazy state by the team instead saying “we only need to forecast, it’s OK if we miss some stuff, we can figure it all out later.”

What Scrum.org say about “Forecast” or “Commitment”?

There’s an immediate reason for the change, which has to do with the meaning of the words themselves. The word commitment usually relates to undertaken duties. After committing to deliver a list of Product Backlog Items, the Scrum Team, foremost the Product Owner and especially the stakeholders may feel that there is an obligation to actually deliver all of them at the end of the Sprint. But reality keeps on showing us that it is difficult, if not impossible, to always fulfill this self-imposed commitment without making compromises to quality. A Sprint Backlog is complex enough that uncertainty is always present, and common sense tells us that we shouldn’t promise what we are not sure to be able to deliver. When we use the word commit, we can be easily biased towards that duty-obligation-promise way of thinking.

My Personal Opinion:

I think both sides has the sound rationale behind. What is your comments and opinion?