Reaching Sprint Commitment

The Scrum Primer discusses "Sprint Commitments" as an outcome of the Sprint Planning. This Sprint Commitment means that "the team commits to doing the best they can to reach their target". Often, this is implemented as part of a ceremonious event. The PO asks: "Team, will you commit to this?" - "Yes" - "Go". This, however, is a "Commitment Cargo Cult": It's not how you reach Commitment.

What Commitment is

Based on the "Chicken and Pig" Metaphor, Commitment is an exclusive dedication to a specific purpose.
In Scrum, it is actually desirable that a team exclusively focuses on the specified Sprint Goal. As such, gaining the team's commitment is highly desirable.
However, "exclusive dedication" has a bigger scope than stating to dedicate a couple weeks to a specific topic. Commitment is also a state of mind.

Let us take the example of an Ice Cream Seller at the corner. Maybe he really loves selling ice cream, he enjoys making fancy ice cream cones with perfectly round scoops and some decoration on top. This seller is 100% committed to selling ice cream. His actions are ruled by his love for ice cream.

Now, let's look at the other seller across the street. She is a hired hand, with small children. She, too, sells ice cream as a full time job - but she is actually committed to taking care of her family. Her actions, including the very fact that she is selling ice cream, are ruled by her love for her family.

Both will dedicate 8 hours a day to producing ice cream, and both will strive to sell as much ice cream as possible. But their motive is different. The first seller will continuously think of ways to produce even better ice cream - not because he wants to earn more money, but because he likes to do that. The second seller will spend as little time as possible with ice cream, even during work she will use any free minute to think of their family. She will only think about ice cream sales when the sales are going down (because that affects her directly), but she will not think about new ways of serving ice cream proactively.

We can see very clearly that "commitment" is not really about asking someone to do a certain piece of work, but much deeper.
Developers obviously also have a family life and they have all the right to have this. Let us ignore how much % of their time they spend with work and how much without - but when they work, they should be committed to developing a great product - and not to spend their time doing as much work as possible.

Gaining Commitment

As a Product Owner, you need the team's commitment to plan the next steps.
However, do not ask for a statement of commitment. People might "give commitment" just to get out of a long, boring meeting. They also might "give commitment" because they don't even understand what the problems will be.

You should ask the opposite questions: "What will stop us from reaching this?" - or, "Is there anything that makes you uncomfortable with this goal?"

When developers come up with their own plan for the sprint and do not see road blocks, you can count on their commitment.

Plan Commitment

As a Scrum Team, your responsibility is commitment to a Sprint. 

In Agile Software Development, we never commit to a plan. This is based on the 4th Value of the Agile Manifesto, "Valuing Responding to Change over Following a Plan." What this means: By all means, make a plan, but commit to the goal - not to the plan! Accept that even during the sprint, we may discover information which invalidates the plan.
As team members, when discussing the Sprint Plan, you should not be asking the question, "Can we do all of this?". Much rather, you should ask: "Does it make sense to do this?" - and: "Can I work with this?"

Commitment Culture

As a Scrum Master, your responsibility is that the team is committed.
Your approach to creating commitment should never be focused on method or applying pressure.
Here is a three-stage approach to gaining commitment.

In the first stage, you take the backseat. Do not ask the team to commit - and do not ask the Product Owner to ask for commitment. Observe if the team is actually committed.
During planning, there are a few very good indicators on team commitment. For example, team members who fiddle on their smart phone rather than asking questions are probably not committed.

In the second stage, you move into the passenger seat. After you have a good idea on who is not committed, you must find out the reasons. Taking personal reasons out of the equation, you usually have either organizational or product related issues which impede commitment. Aside from observing closer, you may want to seek the dialogue with people are not committed. Careful - you do not want to suggest they are performing inadequately. You want to find out what could be changed in the organization so that they can commit better.

In the third stage, you must move into the driver seat. Understanding the root causes of lacking commitment, you create transparency around the issue and involve those who can actually do something about it. This may be the Product Owner who is asking the wrong questions to the team - it could be managers giving perverse incentives to developers or just those in charge of existing bullshit processes - or many other things.
Your goal is to change the organization so that developers can commit.

Then, you go back to Stage One - and observe if the situation has improved.

Summary

Sprint Commitment is not a statement during Planning. It is a mindset within the team - and to achieve this mindset, you must have a culture that allows developers to truly commit.
This culture requires a clear goal to orient on (Purpose), developers owning the solution by themselves (Autonomy) - and having what it takes to actually do something meaningful with this goal (Mastery).

You will never gain proper "Sprint Commitment" without this basis.