Scrum is based on short iterations, typically 2-3 weeks. This is great for fast adaption and product delivery. This approach has the disadvantage as well. The product delivery and development needs to consider long-term and mid-term planning as well.
Practicing Agile in the real life proves that mid-term planning is necessary for successful product preparation and planning. Agile teams usually introduce a release cycle (or program increment cycle) which is comprising 3-5 sprints.
Release planning cycle (the first sprint is even planned as well)
The release does not mean deployment of a new version. Deploy can be done based on requirements. In some companies it is at the end o the release cycle, great agile companies are able to deliver a new version at the end of every sprint, perfect one delivers more times per day.
The release cycle is the planning cycle. Planning with the medium-term horizon of the team allows having a vision for the future so the architecture or design of the planned features can be adapted without having to redesign them.
Release backlog prepared for the release planning session
The duration of the planning meeting depends on the length of time for which it is intended to work, the complexity of the requirements and dependencies on other systems. In practical life, it appears that the release planning typically takes one day. In more complex cases, it may also be three days.
To know plans for a longer period of time.
To identify the connection between the version and the vision and product strategy.
To introduce features, epics and their splitting into user stories.
To identify risks.
To identify constraints to the completion of the features.
To set the correct order of the requirements.
To schedule requirements into the sprints.
To roughly estimate the severity and complexity of the requirements in story points.
To identify dependencies on other systems.
To coordinate development plans of the dependent systems.
To identify the missing information.
To understand the release intention of the whole team.
To agree on critical dates and milestones.
The Product Owner explains:
Stakeholders and clients who will be affected by the given version and for which the features are developing.
Personas for which the features should be developed.
Features, Epics or User Stories.
Splitting the Epics into more detailed User Stories. This is done by the team members in some teams.
Definition of Acceptance criteria. They don’t need to be absolutely precise, the level for the rough effort estimation using the Story points is sufficient.
Organizes the meeting.
Moderation of the meeting.
Provision of the necessary material for the workshop.
Evidence of risk.
Joint synchronization of the teams with coordination with other ScrumMasters in case of planning with more teams.
Understanding of the requirements.
Splitting the Epics into User Stories (in agreement with the product owner).
Assistance with the definition of acceptance criteria.
Identification of risks.
Estimation of the implementation complexity.
Review the requirements ordering.
Identification of dependencies on internal or other systems.
Writing the requirements to the product backlog (depending on the agreement with the Product Owner).