Is the PO Responsible for moving/deciding which Tickets to move Between Sprint Backlogs?

Now you, as the PO, have to decide which user stories/bugs should be moved from the next sprint to the current one to be worked on, since the developers currently have more capacity for additional tickets."

The SM is partially correct. However, unfinished work from the current Sprint Backlog moves back to the Product Backlog. Unfinished work does not automatically roll over to the next Sprint Backlog. As a Product Owner, you can decide if there is still value and an ROI on those unfinished PBIs or if some other PBIs have become more important.

developers are responsible for the sprint backlog

The Product Owner is accountable for the Product Backlog. Developers are accountable for the Sprint Backlog, for meeting the Sprint Goal (which is part of the Sprint Backlog), and for pulling work from the Product Backlog into the Sprint Backlog, once the Scrum Team comes up with a Sprint Goal.

So according to her, it was up to me to decide which tickets should move from one sprint backlog to another.

The Product Backlog items selected for a Sprint are a forecast of work for meeting a Sprint Goal. That's decided by the team in Sprint Planning, not in advance by the Product Owner. The Sprint Goal ought to be a timely commitment for the Sprint.

What a Product Owner should do is to order and organize the Product Backlog, so the work at the top of the Product Backlog will be considered first in Sprint Planning, and product value delivery thereby optimized.

If the Developers have already met their Sprint Goal commitment, it would be up to them to decide what to do. They may work with you on selecting other work from the Product Backlog, or they may spend time on Product Backlog refinement, on implementing team improvements, or on whatever else they think best.

The Developers are indeed accountable for creating the Sprint Backlog at the Sprint Planning event and maintaining it throughout the Sprint as a "real-time picture of the work that the Developers plan to accomplish during the Sprint to achieve the Sprint Goal", making it a tool to offer transparency into the progress toward the Sprint Goal to stakeholders.

I'd disagree that a session or event where the team plans the work that can be Done in a Sprint "has nothing to do with what Scrum defines as Scrum events". This seems like a part of the Sprint Planning session. Although the Developers select work and build the Sprint Backlog, this shouldn't be done in isolation. Collaboration, especially between the Developers and the Product Owner, is important to determine what work can be Done in the Sprint and ensure that the selected work is the most valuable work.

I've seen different ways to plan a Sprint. Some teams I've worked with started with a Sprint Backlog that only reflects the work they believe is necessary to achieve the Sprint Goal. If they finish that, they can pull in additional work from the Product Backlog before the end of the Sprint. Other teams want to plan more of their capacity up front, even if not all the planned work is directly related to the Sprint Goal. Neither approach is wrong, and different teams may have a preference.

I find it unusual that the Product Owner would need to determine what work should be done in real-time at an event. The work to maintain the Product Backlog is ongoing. At any point, the most valuable work should be obvious to the team. However, just because the Product Backlog is ordered with the most valuable work readily apparent, the team may not be able to execute on that valuable work until it's sufficiently refined. The Developers are the ones that should be allocating time to either refining valuable work so it's ready for an upcoming Sprint (or, perhaps, early selection if capacity allows) or pulling refined work from the Product Backlog for delivery.

I would not expect a Product Owner to push work to the team, but rather make it easy for the team to find and pull the most valuable work as they are able.

• The PO might say, “These are the highest-priority items,” but the team decides what they can realistically take on in the sprint.
• If tickets need to be moved between sprints (e.g., from one sprint backlog to another), this typically happens during sprint planning or a backlog refinement session, with the PO providing input on priority and the team agreeing on feasibility.

So, to answer your question: No, the PO is not solely responsible for moving or deciding which tickets move between sprint backlogs. It’s a collaborative effort, with the PO setting priorities and the team managing the sprint backlog execution.