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.