Can Product Owner add/remove from Sprint Backlog?

From the Scrum Guide:

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.

Since the Sprint Backlog is the plan for the Sprint by and for the Developers, no one in the Product Owner capacity should be changing the Sprint Backlog. However, there's nothing in the Scrum Guide that prevents the Product Owner from also being a Developer.

The Product Owner should not be changing the Sprint Backlog.  The Developers change the Sprint Backlog.  If the Product Owner feels there is a need to change the Sprint Backlog, that should be discussed with the Developers. Even if the Product Owner is also a Developer, that does not give them permission to modify the Sprint Backlog at will. 

Notice in the quote that @Thomas Owens provided it says "...by and for the Developers." (plural not singular).   There is no single person that can update the Sprint Backlog according to their will. It needs to be an agreement made by all of the Developers.  This prevents any single developer from becoming the decision maker which is what many companies want to have. 

Can Product Owner add/remove from Sprint Backlog?

He or she can remove Product Backlog items from the Sprint Backlog by removing them from the Product Backlog.

if removal or addition of items in the sprint backlog done without the knowledge or acceptance of the developers then that is to be fixed. As you know changes in the sprint backlog should not impact the sprint goal. If PO feels Sprint goal is not valid anymore, the sprint can be cancelled and start with new one.

Daniel and Ian, it seems you guys disagree?

No, we have differing opinions based upon our experiences.  This is not the first time we had differing opinions and it won't be the last. I highly respect @Ian Mitchell as I do everyone that posts on these forums.  They help add to my experience and have impacted some of my opinions over time. That is the wonderful thing about agile software development and the Scrum Framework.  There is not a single correct answer.

In various parts of the Scrum Guide (2020) we can read that Sprint Backlog artifact is created by and for developers. It is created during sprint planning and is clarified as more is learned. It consist of Sprint Goal, selected PBI, and plan for delivering them. And what is worth to mention, PBI that not met DoD can not be released and return to Product Backlog for further consideration.

IMHO that guide us into scenario where once selected PBIs can not be easily removed from Sprint Backlog by PO. Which leaves him with either collaborating about that with developers, or canceling the sprint. Strategy suggested by Ian in my opinion does not align with the Scrum Guide. We can conclude that by this remark about not Done PBI. In order to return something, it must be absent in the first place. So the moment when PBI is selected for sprint, PO lose full control over it as it is no longer part of the Product Backlog for the duration of the Sprint.

However, that does not mean that PO have no voice, he is still part of Scrum Team and the entire team is accountable for the sprint and is empowered to self-manage their work.

In other words the PO must collaborate and not act as a dictator, as the power to manage Sprint Backlog is within the Developers. PO’s dictatorial power is here limited to special card “cancel the sprint if the sprint goal is no longer valid” 😉

Daniel and Ian, it seems you guys disagree?

Possibly, but this is no evidence. One of us has described what a Product Owner can do, the other what a Product Owner should do.

In the past, I have successfully been able to explain to Product Owners why it would be a bad idea for them to add things to the Sprint Backlog, rather than to take it to the Developers, and have them make the decision:

Pulling extra work might mean that it is not possible for the people doing that work, to also do something else. It may even put achievement of the Sprint Goal at risk.

By having the Developers choose what to say “yes” to, they can ask what it is OK to say “no” or “not now” to.

Then that work can already be removed from the Sprint Backlog, rather than avoiding that decision and causing disappointment at the end of the sprint.

It enables a more informed, collaborative, and explicit decision to be made.

If necessary, the ultimate explicit decision that could be made would be for the Product Owner to cancel the sprint. This would be a clear choice to abandon progress towards the current Sprint Goal, and replan.