Change in priority

Where does this question come from?

What is a "Product Manager"?

Why is there no mention of a Sprint Goal?

3 is the only answer I can see really making sense from a Scrum perspective, but really they are all indicating something that isn't scrum practice. 



The question as Ian alludes is 'What is the sprint goal'? 



If the story helps achieve the sprint goal, and can be pulled in or replace existing stories without risking the sprint goal, then there's no real issue, but that's for the team to decide, not the PO (or certainly, the non-existent role of PM) 



but in reality, they're probably talking about something unrelated to the sprint goal, so it should go to the product backlog to be prioritized by the PO and potentially pulled in for the next sprint. 



Underpinning all of this is the part that makes me most uneasy which is the word 'Client'. 



A Scrum team is essentially a product team. They should care about customers. Client starts to sound like they are some sort of waterfall delivery team delivering specs for some single stakeholder. What the 'client' wants is only relevant as a key stakeholder. 

The team should be guided to deliver the product goal for our customer, as guided by the PO.

Where did this question come from? With terms like "Product Manager" and "user story", I'd question if the author understands the Scrum framework well.

Looking at the answers, none are really that good.

Tell the client that stories cannot be added mid-sprint for any reason

This isn't true. The Developers manage the Sprint Backlog, so the Developers would need to be the one to make the decision on if it is feasible to change the work in the Sprint Backlog. This decision should be made against the ability to achieve the Sprint Goal. Perhaps it's communicated to the stakeholders by the Product Owner, but it's generally not the Product Owner's decision to make.

One case where it could be up to the Product Owner is if the work represented by the new Product Backlog Item is less important than anything that the team selected for the Sprint. Even though the particular stakeholder may believe that it should be more important or of a higher priority, the Product Owner is accountable for making the decisions regarding ordering the Product Backlog. The Product Owner could make the decision to not bring the new work to the team because they feel it is less important than the work currently being done.

Work with the team to determine what can be pulled out of the sprint in order to add this feature in

This is a viable option, but not always true. There are two key factors missing.

First, there's no mention of the Sprint Goal. The purpose of a Sprint is not to deliver all of the selected Product Backlog Items, but to achieve the Sprint Goal. The team should first determine the impact of this new work on the ability to achieve the Sprint Goal. As long as the Sprint Goal is not obsolete, then that should continue to remain the commitment of the team.

Second, this doesn't account for good capacity planning on the team's part. A team that regularly receives ad-hoc requests should leave a buffer in their capacity for those high-priority ad-hoc or unplanned requests so they can take them on. The Sprint Goals should be crafted with this in mind. A team at full capacity also leaves no room for any unplanned occurrences. Perhaps it's not unplanned work, but an unplanned reduction in capacity.

Speak to the client about the impact of swapping in/out user stories

This is also a possibility. However, it doesn't mention the Sprint Goal. Perhaps that's implied, but I'm not sure that it is given the other problems with the question and answers. Any conversation about impacts should consider things like the Sprint Goal, the team's capacity, and the ability to maintain a sustainable pace.

Let the client know that the feature is not as important as he believes and that there are other priorities that provide more value

This is an option as well. However, there's insufficient context to know for sure if the work is or is not less important. The Product Owner is definitely the person accountable for making the decision around ordering the work and maximizing value. Especially in cases where there are multiple stakeholders, the Product Owner needs to balance the needs or demands from all of them.

Stop sprint work, and replan the remainder of the sprint with the new requirements from the client

This is an option in Scrum - the Product Owner has the ability to cancel the Sprint. However, it's not commonly used and is a very extreme option. It should only be used in cases where the Sprint Goal is obsolete. Since there's no mention of the Sprint Goal in the question or answer, I'm not sure that this is the case.

From a Product Owner's perspective, 3 and 4 are something that the Product Owner can do on their own. 2 is also a viable option, but regularly being in a position where 2 happens is often indicative of other problems. 5 is also a possibility, but not one that I would recommend. It's not clear what the correct answer is. I think there's insufficient information to support 4, so I would probably lean toward 3 as a generally good thing to do. If this happens frequently, solving the root causes would be a much better choice.

Like everyone else, I question the knowledge of the person/organization that wrote the question.  It has nothing in it that references the Scrum framework other than the use of the word "sprint".  Even if I use my imagination, I can't get it to relate.  

So my answer to your question is that you already know the answer and you should stop using the information from the organization where you found this question. 

Well thanks to everyone who took time to give his thoughts on that.

I found this question in the knowledge base of my company. There is a quizz, but without even the correct answers.

I'm glad to know that none of these answers are suitable as I didn't know how to answer :D