adjusting sprint backlog during sprint

I would stick to the scrum guide. As you pointed out:

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Take note that it's up to the team to decide wether or not they can meet the commitments of the sprint. If it turns out that some goals cannot be met, the PO should definately be informed so that commitments can be renegotiated or canceled altogether.

Since the metric is in "points", you cannot use that to accurately plan wether or not the goals can be met. Within the sprint, there is more information available to the team to use to determine if they can make their commitments.

With that said, I don't see A as a valid answer.

B isnt valid because sprints are timeboxed and of fixed length.

C isnt valid because it is up to the dev team determine progress towards their commitments, not the PO.

D isnt flat out invalid but also isnt clear cut valid for reasons you've pointed out.

As such, D is the "better" answer of the 4.

I'd go with A... what's the point in trying to complete more than the team can - would that not just cause them to cut corners and introduce technical debt ?

Also, I'm struggling with the idea of "The Sprint Backlog is frozen when the Sprint Planning is done, and no one can change it for any reason." - something might not be needed any longer, so would you still build that 1 item

I won't choose A, because it is not up to the dev team to decide on their own with item will return to the PB.
I won't choose B, because the sprint length is time boxed
I won't choose C as it stand : I will inform the PO, and maybe the PO + the dev team will decide together what to do (or not to do) by now.
I won't choose D as is stand, because the dev team should have the courage and transparency toward the PO. We don't have the full context, but maybe the item will not be finished, but the sprint goal will be met.

C is the best answer, however it should read "They should inform Product Owner and renegotiante with him". This may result in A, but they cannot start with A without informing the Product Owner.
All other answers cannot be true: B violates the Scrum Framework, and C violates the Scrum values openness, courage and committment.
The "correct" answer and explanation given by Management Plaza is hilarious.
This is not the first occurrence in this forum.
I don't know why people keep on refering to them.

Statement:
"Correct answer suggested by Manual is D with the following explanation:
The Sprint Backlog is frozen..."
Where does it come from? I just found in the Scrum Guide:
"No changes are made that would endanger the Sprint Goal"

So I would think the best way is to adapt and refine the Sprint Plan (with the PO) to meet the Sprint Goal.

From the Guide:
"The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog."

Imagine what happens if you have not planned all the selected PBIs in your Sprint Planning? Time was up. So you have to get started with your work and live with the incompleted Sprint Backlog. You have to close the gaps during the Sprint and work with the PO on it.

From The Guide:
"The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner."

So in my opinion the Statement that the Sprint Backlog is frozen is just wrong. For me this comes near to answer C where the Team renegotiates the selected Product Backlog with the PO, but the PO decides what is acceptable to reach the Sprint Goal.

Kind regards

Benjamin

> Correct answer suggested by Manual is D with the following explanation:
> The Sprint Backlog is frozen when the Sprint Planning is done, and no
> one can change it for any reason.

This is absolute nonsense.

> So I would think the best way is to adapt and refine the Sprint Plan (with
> the PO) to meet the Sprint Goal.

Correct, that would be the appropriate course of action. The estimates can be updated, and the Sprint Backlog revised, but there is no need to remove any work from an agreed backlog unless the Sprint Goal is in jeopardy.

This usually happens. As more is known about the work, scope can be renogiated with the product owner, after you have identified potentially dangerous variances that could endanger sprint goal. The purpose of inspection is to adapt, and adapt as soon as you discover new information. You must discuss with the PO and PO has to make hard choices on some use stories which cannot be developed 

A seems to be closest the the right answer. 

Such wide variances in user story estimates between the time you plan and time you start to develop should not happen frequently, and it would be a good point for discussion during retrospective - "how to come up with better estimates"".

The Development Team realizes that the volume of work of one of the items in the Sprint Backlog is estimated incorrectly, and the current volume of work of the whole Sprint Backlog is 130 instead of 100. What should we do?

A. They should return some items back to the Product Backlog to keep the Sprint Backlog volume to about 100 points

The development team itself can not return some items without discussing with Product Owner (wrong answer)

B. They should ask Scrum Master for more time for this current Sprint

Each sprint is time boxed. So this is not correct (wrong answer)

C. They should ask Product Owner to decide on this

D. They shouldn’t do anything now

It is always possible to discuss with Product Owner. Only product owner can decide on the adjustment in sprint backlog. doing noting is not a best possible situation / solution (wrong answer)

So option C is best answer.

The one thing that stands out to me with this old exam question is that the issue is around a potentially incorrect estimate.   Estimates are basically best guesses by the team based on the information on hand, and there is always the possibility of an estimate being smaller or larger than it should have been in hindsight.



What to do when the team realizes this?   I would say nothing, save for the team potentially adjusting the Sprint Backlog (de-scoping or adding items) based on the change in scope, as long as the Sprint Goal remains viable.



Such an adjustment would be nice to coordinate with the Product Owner, but that is not a requirement in Scrum.



Per the Scrum Guide:

The Sprint Backlog is a plan by and for the Developers... the Sprint Backlog is updated throughout the Sprint as more is learned.