The Scrum Guide doesn’t mention this issue. As you will see for good reasons.

Answer 1: Clearly, thats the job of the ScumMaster

There are good reasons that the ScrumMaster is the right person.

He has (hopefully) the most knowledge about Scrum
He is the (servant) leader
The Scrum process is in his responsibility

Answer 2: Clearly, thats the job of the Product Owner

And again, there are good reasons that the Product Owner is the right person.

He is the one who is able to determine how long he can wait to review outcomes
He knows how often stakeholders are available to review outcomes
He knows how often the Customers are able to review outcomes

Answer 3: Clearly, thats the job of the Development Team

And again, there are good reasons that the Development Team is the right choice.

The know how often they can show their outcome
The know how long the build of a potential shippable increment take.

Answer 4: Clearly, all have to be involved

And again, there are good reasons for this approach.

Nobodies opinion is unheard
A consent is always a good base for commitment

Please, choose correct answer;)

1, 2, 3, 4, 5, I don’t know

In my opinion, expect „I don’t know“ all other answers are to easy to be true. The reason is, I forgot to add some context.

Now let’s add a little bit context.

The ScumMaster could be a choice if everybody is new to Scrum and weather PO, nor PM, nor Development Team have any objectives.

The PO has a strong saying, because he is aware of the important factors like his own need to change direction.

If there is only one (or two) mature team(s), than asking the team could be good way.

Having a consent decision, could be a way, but doesn’t reflect that the PO owns the most import factors.

At the end, dependent on the project context there can be hard company constraints which has to be followed.

You want some more context?

One day (I was the ScrumMaster) the PO ask me to help him because in his backlog were several not cleared items. He was in fear that with the current sprint length of three weeks he’s not able to meet the release goal. Unfortunately, the two development teams continuously weren’t able to deliver all forecasted sprint backlog items. A continuous integration was established. In his opinion a two week sprint length would help him a lot. The company standard was two weeks as sprint length. The Management votes for two week sprints to align the project. Because each of the developments teams are distributed to three locations is was difficult to schedule video conference rooms for the scrum events without collisions every third sprint. The development teams were known for their resistance to change.

Pro’s

PO want’s a reasonable change
Development teams are not mature enough to meet forecasts. Shorter sprints could help them
Integration isn’t an issue
Company alignment reduces complexity
Changing the sprints length without developing team involvement will lead to a discussion about the meaning of self organization and the fear behind the Development Teams resistance to change - Sometimes SM’s need’s to be a little bit evil

=> For the overall system a change to two week sprint length is useful and should be done.

Don’t ask me what happened three weeks after I announced that the sprint length is subject to change. As mentioned before, the teams were known for their resistance to change and for sure they don’t want to talk about their fears ;)

I hope this explains why the Scrum Guide is that silent on this topic.

My 2 Cents

Who determines the Scrum Sprint length?

Product Backlog Issues Part 1

Scrum Alliance vs. Scrum.org Zertifizierung