The Sprint Planning event marks the start of a new Sprint. During the meeting, the team plans the work that will be done during the Sprint. They do this by selecting items from the product backlog. This implies that there should be a set of product backlog items ready for development. It is the job of the Product Owner to have these items ready. The PO, however, should strive to have more than one Sprint worth of product backlog items, in case the development team is able to commit to a larger list than expected. In addition, the PO should include less refined items in the product backlog that extend, at least, to the next planned release. There is nothing wrong with planning ahead if we recognize that the plan might change and the further the planning-horizon, the higher the probability that items will change. A high-level or program-level plan does not have a lot of changes from one Sprint to the next, so nothing wrong in having a longer-term plan, as long as everyone agrees that it is an estimate and that it can change as we validate it from Sprint to Sprint. This coarsely grained to a more refined set of items is easier to visualize and plan by performing a story mapping and holding continuous Sprint planning activities.
Question of the Week - How far ahead should an Agile team plan?
Updated: Nov 4, 2020
You should be releasing to production when ready and not planning out releases into the future. There definitely should be a good set items in the product backlog to bring forward.
I agree that 3 iterations worth of ready PBIs is a great position to be in. However, be careful not to do this at the cost of less refined PBIs for the closer Sprints.
Wouldn't it be good to have at least 3 iterations worth of backlog ready at any time...?