Scrum is based on short iterations, typically 2-3 weeks, in which the development team together with the Product Owner and Scrum Master deliver the slice of the product backlog.

This is great from the perspective of fast adaption as product delivery can be adjusted based on the need. However, such an approach has disadvantages as well. The product delivery and development needs to consider long-term and mid-term planning as well.

Practising Agile in real-life proves that mid-term planning of release cycles is necessary for successful product preparation and planning. The agile development team usually introduce agile release planning. The release planning covers the release cycle (or program increment cycle) which is comprising 3-5 sprints. This approach helps keep a long term perspective of the product plans and drives further development of high-level requirements.

The Product Owner can do long-term planning of the release schedule with a bigger iteration, the Program Increment. Epics or high-level requirements are slotted for particular Program Increment (release on the picture below). Program Increment delivers one or more Epics.

User stories defining the Epic assigned into the Program Increment are still planned by the Scrum team in sprints. Not all epic user stories must be developed in the Program Increment. The Product Owner should consider Minimum Marketable Product (Minimum Viable Product) to gain the speed of the value delivery.

Release planning cycle (the first sprint is even planned as well)

Release, Deploy, Program Increment

The release on the picture above represents the larger time-box, the Program Increment. It does not mean the deployment of a new version. That was the terminology used by agile teams a few years ago. We put it here for sake of clarity. The terminology has changed with new frameworks supporting scaled agility, i.e. Scaled Agile Framework.

If the development team is capable, there can be multiple releases, deployments, in every Program Increment. 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 agile development teams deliver even multiple times per day.

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 agile release planning meeting (or Program Increment Planning meeting) depends on the length of time for which it is intended to work. The complexity of requirements and dependencies on other systems should be considered in the setup of the agile release planning meeting as well.

In practical life, it appears that release planning typically takes two days. In more complex cases, it may also be three days.

Goals

1. To know plans for a longer period of time.
2. To identify the connection between the version and the vision and product strategy.
3. To introduce features, epics, and their splitting into user stories.
4. To identify risks.
5. To identify constraints to the completion of the features.
6. To set the correct order of the requirements.
7. To schedule requirements into the sprints.
8. To roughly estimate the severity and complexity of the requirements in story points.
9. To identify dependencies on other systems.
10. To coordinate development plans of the dependent systems.
11. To identify the missing information.
12. To understand the release intention of the whole team.
13. To agree on critical dates and milestones.
14. To understand the requested release schedule.

Who

Product Owner

In the agile release planning session, the Product Owner explains:

1. Release goals.
2. Stakeholders and clients who will be affected by the given version and for which the features are developing.
3. Personas for which the features should be developed.
4. Features, Epics, or User Stories.
5. Splitting the Epics into more detailed User Stories. This is done by the team members in some teams.
6. 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.

ScrumMaster

1. Organizes the release planning meeting.
2. Moderation of the meeting.
3. Provision of the necessary material for the workshop.
4. Evidence of risk.
5. Joint synchronization of the teams with coordination with other ScrumMasters in case of planning with more teams.

Team members

1. Understanding of the requirements.
2. Splitting the Epics into User Stories (in agreement with the product owner).
3. Assistance with the definition of acceptance criteria.
4. Identification of risks.
5. Estimation of the implementation complexity.
6. Review the requirements ordering.
7. Identification of dependencies on internal or other systems.
8. Writing the requirements to the product backlog (depending on the agreement with the Product Owner).

Release Planning Meeting Agenda

Release planning agenda

The expected outcome of the release planning meeting

• Identified epics and features of the product.
• Identification of stakeholders and personas.
• User stories are slotted into individual sprints.
• User stories are estimated in story points.
• Risks identified.
• Dependencies on other systems identified.
• The team is committed to the version delivery.

How ScrumDesk supports release planning?