One of the most important steps in the release planning process is defining the vision for your product. The vision will guide subsequent decisions on which features to prioritise, where to focus effort and resources, and how to adapt if the project requires adjustment during development. All the above aspects contribute to maximising the chances of achieving the desired outcome.

As a first step, an organisation must determine the proper cadence for releasing features to its customers. Some organisations decide to release every Sprint, while others combine multiple Sprints into one release and others release just after the completion of each feature, this practice is called Continuous Deployment or Continuous Delivery.
Whether the organisation intends to deploy every Sprint, every few Sprints, or continuously, they find some amount of longer-term, higher-level planning to be useful.
The process involves determining the work to be done, understanding scope, date and budget constraints, monitoring progress from Sprint to Sprint and making adjustments as required. It involves the entire Scrum team and the stakeholders. At some point, the involvement of all these people is necessary to maintain a good balance between value and quality.

Before starting the release planning and creating a release plan, the following must be available:
- A product backlog, which has been prioritised and estimated.
- How much work the Scrum team can complete per iteration (Velocity).
- The agreed goals for the scope, schedule and resources.

As I have already mentioned, the constraints of scope, date, and budget are important variables that affect how we will achieve our goal. These constraints are either fixed or flexible. I will describe two realistic options to create our release plan, depending whether the project is feature-driven or date-driven.

Feature-driven
A feature-driven model is appropriate where the scope is more important than the date. In this model, when we run out of time and we haven’t completed all of the features, we extend the date to ensure that we get everything required.
If we are doing a feature-driven release, we must know what the features are at the start of the release.
This is usually true when we are building a simple or familiar product. In case instead we are developing innovative products, many features will emerge and evolve during the development effort. We certainly have some idea of the desired features up front, so we will use them in our initial release planning. However, we must be prepared to continuously revise our release plan as our understanding of the required features changes.
If an emergent must-have feature appears, we will simply add it to the scope of the release and push out the release date.
During feature-driven planning, we need to calculate the number of Sprints required to deliver the fixed set of features. The number of Sprints needed to complete the release is determined by using the sum of all features divided by the expected Velocity of the Scrum Team.

Date-driven
Many people consider this to be the approach most closely aligned with Scrum principles. We can fix both the date and the budget, but the scope must be flexible. The Scrum principle of creating the highest-priority features first should alleviate any pain of having to drop features. When we run out of time on a date-driven release, whatever has not yet been built should be of lower value than what has already been built, therefore it is much easier to make a decision to ship if the features that are missing are low value.

Assuming that the length of each Sprint is the same throughout this release, which is the normal case with Scrum, to find out how much work can be completed within a given time-frame, the Velocity of the Scrum Team is multiplied by the number of Sprints.

The outcome of the Release Planning is a release plan that communicates when we will finish the product, what features we will get at the end, and how much will be the cost. Of course, assuming that we proceed with the release, we must revisit our release plan every Sprint to update it based on our current knowledge.

In order to have the best release plan possible, here are five tips I find useful when I perform with a team this kind of planning:

Keep the Focus on Goals. There’s a lot to take into account when developing the release plan. You can easily get lost in the weeds. You want to keep your eyes on the priorities: goals, benefits and results. Features contribute to a goal. Focus on the goal and the feature will follow.

Identify Task Dependencies. Dependencies are tasks and User Stories in the Product Backlog that cannot start or end until another starts or ends. If you’re not aware of the dependent User Stories in your release plan, you are going to suffer delays and block your team. By identifying these User Stories beforehand and making sure you stay aware of them, you’re going to keep the Scrum Team working without unnecessary interruption.

Release Often. The mandate of any release planning is to release your product to customers. Only then will you be able to determine if the User Stories you released were of value to them. Therefore, release often. Smaller releases are easier to digest for customers than having a couple of big ones per year.

Release Done Work. It might sound obvious, but often work in the Product Backlog is moved forward through production without being completed. These incomplete User Stories can involve a lot of time and money to fix. That will take away from your main goal, which is delivering value to your customers. Have a Definition of Done for your User Stories and product deliverables and stick to it.

Continuously Improve. Good enough isn’t good enough. There will always be room for improvement, but like release planning these improvements should be applied incrementally. Give them time to prove themselves.

Source:
This post was inspired by Essential Scrum, a practical guide to the most popular agile process and
5 Tips for Better Agile Release Planning