Pre-seeding Sprints for a Release

My product owner has prioritized the backlog and pre-seeded 7 sprints for next release

What is happening in the other 6 Sprints?

The Scrum Guide says "The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint", and "Sprints are the heartbeat of Scrum, where ideas are turned into value."

How do I help my PO understand that this is not appropriate and that the teams should help with seeding future sprints

Can you clarify what you mean by the "seeding" and "pre-seeding" of future Sprints? Who is making commitments here?

What you have described sounds like a waterfall culture to me: one in which significant leaps-of-faith are taken before any outcomes are obtained. Perhaps the first thing to do is to determine whether or not this risk to value delivery is acceptable, and whether the complexity of the work justifies the use of Scrum at all.

If you want to use the Scrum Guide, I'd point out to the Product Owner that there are only two backlogs. The Product Owner is accountable for managing the Product Backlog, which includes creating and ordering Product Backlog Items. The Sprint Backlog does not exist until Sprint Planning, when it is created by the Developers in collaboration with the Product Owner. There are no Sprints or Sprint Backlogs in which to place work prior to Sprint Planning, and the Developers will be fully accountable for creating and maintaining the Sprint Backlog.

If you want to talk more generally, I'd point out that laying out work for future Sprints is long-term planning. If you find that an agile approach to carrying out the work is effective and appropriate, that is at odds with successful long-term planning. Anyone who sees this work laid out may begin to build expectations about when work will be started and finished by the team. Long-term planning is antithetical to the agile value of "responding to change over following a plan". As the team does the work, demonstrates or delivers their work to key stakeholders, gets feedback, and incorporate that feedback into the Product Backlog, the order of work will shift, some of the work may be removed because it's invalidated, and new work that is more valuable (and should be done first) will be added.

Thank you, Both! The PO is using the sprints (there are only 7 in the entire release) as a way to help him organize different areas of the product by value to the customer. So instead of using the main product backlog as his prioritized list, he pulled in some of the items for sprint 1, and others for sprint 2, and so on and so forth. We're in sprint 1 and there are work items in all of the sprints of the release due to the PO putting them in there. He's saying that he did this last release and it worked fine so why change it. I'm trying to protect the team and ensure they have a say in how the future sprints are planned for. So in general, we should not be populating future sprints with work that we know will be in the release?

The PO can order the Product Backlog as they see fit, which could include order in accordance to what they see as most valuable or hope to focus on first, next etc. This is not the same as pre-determining Sprints. 

The Sprint Backlog is not even part of the PO accountability. 

From the guide…

"The Sprint Backlog is a plan by and for the Developers."

As mentioned above, the Sprint Backlog doesn't even exist until Sprint Planning occurs, and only exists within the Sprint they are created.

Are Developers and their accountability being respected in this scenario? Should they be expected to commit when someone else has made the commitment on their behalf? I would say no applies to both.

It seems like the PO is attempting to use Sprints to deliver a sequential plan. Waterfall through iterations. If the problem being solved for this product is complex, there really is no way to actually predict what will happen each Sprint. You may find with the first Sprint that the work is much more complex than you initially thought. 

"as a way to help him organize different areas of the product by value to the customer."

While we can assume value to the customer, it is only a hypothesis until such time that we build and release an Increment to them. It is the customer who determines if the product increment is valuable or not. This won't happen in this case, until you complete the planned release, 7 Sprints later as you mentioned.

Where in this pre-planned set of Sprints do we account for Stakeholder collaboration and input? For inspection and adaptation? What if the direction changes completely based on Stakeholder need or market changes? 

We leverage empiricism so we can gain experience and inspect and adapt. Solutions emerge with this discovery and learning. Pre-established Sprints or plans won't leave much room for this.

Gia - As you know this is a very bad practice.  First, try to convince him that you should pull the items into the Sprint only during Sprint Planning.  All the work should remain in the backlog, in a prioritized state.  This makes sure that the highest priority items are available to bring in for future sprints. There's nothing wrong with him keeping a spreadsheet or using labels/tags on the tickets it he wants to "pencil in" stories for the sprints for planning but nothing should be in a sprint until sprint planning.

The Scrum Team decides what gets into the Sprint.  So, even if the PO puts items in the sprint, the scrum team has (should have!) the authority to remove items from the sprint during sprint planning and replace with other more appropriate items.  Also, only the Scrum Team decides how much work can be completed in a sprint.  I imagine the PO is trying to dictate that also.

From the sounds of it, the PO doesn't understand agile or the role of a PO.  Maybe suggest he get certified as a PO in Scrum.org?  This will help him to understand his role and hopefully make your job easier.  He's the Product Owner, not the Product God.

Good luck!

Thank you for the insights! This is helpful and should give me some support when speaking about this issue.