PO-driven overload

Establish transparency over the situation so the evidence is clear. Find out who in the organization actually wants change to happen, so realistic commitments can be valued and met.

Why is the PO doing this? 

• Is he under external pressure?
• Is he unstructured himself?
• Does he feel that the developers could be doing more? And if so, is he right?
•  ...

How does the PO add stories? 

• Does he add them to the product backlog, making it longer and longer? 
• Or does it add them to the sprint backlog?
• ...
   

@Ian, Transperency is established already reason why we could easily notice the changes.

@Benedikt, it's obvious that his additions are made directly on the sprint backlog. This is an anti-pattern that is already affecting the developers in a negative manner.

"@Benedikt, it's obvious that his additions are made directly on the sprint backlog."

Yes, I thought so too, but I wasn't sure.

However, the question of 'why' (see above) is still important in order to find a suitable solution.

You can reject the changes during the sprint. Scrum is on your side here.

However, that won't solve the problem that the product owner obviously has. The conflict will continue to fester. In the worst-case scenario, it will continue beneath the surface.

Do you have a team working agreement? Specifically one that defines what happens when the sprint scope changes?

This situation usually improves when the team agrees in advance on how to handle mid-sprint changes. My recommendation is to define a clear threshold that triggers a discussion or replanning. For example, something like adding 5+ points or 2+ tickets during the sprint.

When that threshold is reached, the team either:
• replans the sprint, or
• immediately drops other items to keep the scope stable.

This tends to help in two ways:

1. It forces the PO to engage early instead of continuously adding work.
2. It makes the trade-offs explicit. Something new comes in, something else goes out.

Also, if the team is working overtime to absorb these changes, that’s an important signal to surface (in addition to team health). Overtime has a real cost, and if that cost isn’t visible to the organization, the pressure to add more work mid-sprint rarely changes.

The above posts are all correct, and I will focus on one particular point, as I think you already pinpointed the problem.

... additions are made directly on the sprint backlog. This is an anti-pattern

Yes, absolutely. The team, especially the Developers, should pull in the items they believe they can complete during the Sprint. If the Product Owner adds work directly to the Sprint Backlog, particularly mid-Sprint, then you are not doing Scrum. 

The Product Owner can negotiate scope with the Developers if new work emerges, but they should not simply insert work into the Sprint. Fixing this behaviour would be my first step.

Do you have a team working agreement? Specifically one that defines what happens when the sprint scope changes?

Working Agreement is the Alpha & Omega:

• It defines every expectations
• Team behavior 
• Way of Work (WoW)
• External interaction and much more.

Thanks everyone, your contributions were much appreciated. Everything was in line with my thoughts and some were coined in a very attractive fashion.