Does the Scrum Master have authority over the process?

In other words:

We are in Sprint 1

We have 1 Feature made of 4 User stories. The feature should be finished by sprint 2

So it is made of:

2 small user stories

1 medium user story 

1 large large user story 

We are in the middle of the sprint, we know we can commit to 2 small and 1 medium according to the capacity and velocity. 

I proposed to split the large one and commit to do a part of it this sprint or leave it completely and do it next sprint.  

Lead developer and PO, said that they can not split it. So lead dev proposed to start working on it in Sprint 1 and not commit to it to finish in Sprint 1. 

The Scrum Guide says: "People personally commit to achieving the goals of the Scrum Team". What those goals are is a matter for team agreement, including the Sprint Goal.

In your situation, was the Sprint Goal met, and had the team then agreed to pursue a further goal?

Hi Ian,

thank you for your answer.

Do you mean that as long as the team fulfills the generic goal of the sprint then it is fine to do other work which does not require commitment since they are individual stories and not the main goal? 

I wouldn't describe a Sprint Goal as generic. It leads to a specific, valuable outcome and makes the supporting work coherent.

Once that Sprint Goal has been met, the team can do what they think best with the remainder of the time-box. If they want to make a head start on likely upcoming work, and optimize its flow across the Sprint boundary, they may do so.

Ok, but independently of the sprint goal if we review the definition of increment and the definition of Ready:

Increment 

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprint

Ready and size 

Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning. 

Let’s say from my previous example that they commit to 3 user stories 

1 User Story of 8 user story points

2 User stories of 5 user story points

so let’s say that it is enough for the goal. 

But there is another of 13 points.. too big. The team has 5 points of spare capacity ... so instead of trying to split the use story to finish part of it.. they just start working on it with no commitment since the goal is met?

So in this case velocity acomplished of Done increment is 8 + 5 +5 = 18 points. The other of 13 points they will work but we will not know what they accomplished by the end of the sprint since they did not commit to finish it. 

On the other hand, If that split the 13 points in 2 user stories of 5 points and 8 points user stories. Or pick another user story of 5 user story points instead so they finish the 5 extra user story points we would get 5 extra user story points of increment. This is a testable, usable and submitted to early feedback item.. they could deliver 23 user story points of real, tangible value to the product.. 

According to the Agile principles:

Working software is the primary measure of progress

Additionally starting any initiative that they will not for finish since there is no commitment and urgency to finish it, would they work at the same pace than if they had committed to do it? Psychological speaking would they be motivated to finish the most work they can do on the big user story item by the end of the sprint?  

What does a story point mean?  Does a story point deliver any kind of value to the stakeholder? Why is it so important to deliver more story points in a sprint?  

Story points are estimates made based upon information that you have available.  Once you start working and gain more information those original estimates are no longer valid.  So why is tracking the number of story points "completed" so important? 

The goal of software development is to deliver valuable working software to the people that want to use it.  Typically a user story is a mechanism used to deliver value and it seems to be the case based on your comments.  So wouldn't it be more important to focus on the delivery of stories instead of trying to manage a number of story points? 

The opening sentence of the Scrum Guide where it describes the Scrum Master role says 

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

Where in the Scrum Guide does it say anything about story points or user stories?  Your focus on these two items is not promoting or supporting Scrum.  From that same section of the Scrum Guide I offer these

The Scrum Master serves the Product Owner in several ways, including:

• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
• Finding techniques for effective Product Backlog management;
• ...
• Understanding product planning in an empirical environment;
• ...
• Understanding and practicing agility; and,

The Scrum Master serves the Development Team in several ways, including:

• Coaching the Development Team in self-organization and cross-functionality;
• Helping the Development Team to create high-value products;

If the Scrum Team has agreed upon a plan for delivering the value, you should support it and help them achieve the goal.

You mention the lack of committment multiple times.  Is this because they are saying it won't be finished by the end of the current sprint?  You also state that the team feels that all of the stories can be finished by the end of the next Sprint.  To me that sounds like they are committed to finishing the work as soon as possible.  The Scrum Guide uses the word commit exactly once and it is in the section on the Scrum Values. 

People personally commit to achieving the goals of the Scrum Team. 

Since the Scrum Team (minus the Scrum Master it appears) is setting a goal of completing the set of user stories by the end of the next Sprint, it seems to me they are all in agreement and displaying that Scrum Value. 

That paragraph goes on to state 

The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. 

Seems that the Scrum Team (minus the Scrum Master) has the courage to work on the right thing and that everyone is focusing on the work of the Sprint and the goals of the Scrum Team. 

A Scrum Master does not own the process.  A Scrum Master owns the responsibility to help people be better as a team and to improve their ability to deliver value.  To go even further, Scrum is not a process.  It is a framework that is completely process agnostic. So how does a Scrum Master own a process? I respect Mike Cohn but I have never agreed with him on this point.  In agile the team owns their process.  And in the Scrum Guide it is specifically called out that 

Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

You are there to coach, train and mentor. For the first and the last you need many years of experience, and for the first, some specialized training. In some companies, Scrum Master are put in the uncomfortable position of being shadow managers. In this case, I think that you are upset because the team did not see things the way you saw them. The question is, did the work that was done bring value to the product and to the customer? That is all that matters. Feelings get hurt and paid workers needs to get over them. Everybody has a job to do and in this case, the job is to create a valuable product.

Psychological speaking would they be motivated to finish the most work they can do on the big user story item by the end of the sprint?  

Psychologically speaking, people aren't motivated to finish "the most work" at all. They are motivated when they have an agreed goal to aim for, can bring their creativity to bear in achieving it, and recognize that outcomes are valuable and sustainable.