Agile Release Planning Explained

The Agile manifesto describes the core values and principles that, at least in theory, should guide the whole process of Agile development. One of the core aspects of this manifesto is the continuous value that organizations should provide to their customers. Principles like:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Now, in theory, it may seem to be a great way to create happy customers by providing them with a production-ready product at the end of every sprint. However, providing a working product per sprint is just a narrow way to look at it. As you already know, the project may contain more oversized Product Backlog Items (PBIs) such as Epics and features that will take several sprints (e.g., four to twelve sprints) before they can be released.

Learn what Selenium is and its benefits for automated cross browser testing. See how Selenium works and get ready to use it for testing.

What Is Release Planning?

Release planning is a dedicated meeting for organizations in Agile projects to create a high-level plan for multiple sprints ahead (e.g., four to twelve sprints) and not for a single sprint as it is usually done in the engineering teams. Release planning is vital as it allows all significant stakeholders to assess critical aspects of the project (e.g., risks, resources, tools, etc.), set the initial expectations about which features will be included in each release, and set the goals which the customer/business wants to achieve. In addition to the above, the release planning session allows the three main pillars of the project (i.e., customer, business, and engineering) to gain vital information that serves as a base to track progress within the project timeframe.

A very common approach to determine the amount of time it will take to deliver a specific number of features within a release is to use a simple formula: the number of features within a release / expected velocity = The number of sprints needed to complete the release scope.

Long-Term Planning? In Agile?

In Agile software development, we want to avoid the unrealistic demand to plan the whole release upfront. This is just not the way we do things in Agile. There is no need to invest in large plans that will most likely be a complete waste of time. Now that has been said; we need to remember that we cannot run an Agile software development project without any upfront planning; we must have the minimum understanding of what the customer is expecting to receive and how we will deliver it.

The Prerequisites to Release Planning

The project release planning is a crucial meeting that involves many stakeholders, and we do not want to waste their time. A good approach is to use ‘Entry’ criteria for the meeting that specify simple prerequisites such as:

There is a clear definition of the market objective.
The high-level vision of the product.
A prioritized product backlog including the relevant features.
The average velocity of the Agile teams that will do the work.
List of risks, dependencies, and any gaps that can affect the project.
List of goals and expectations.
Available resources that will take part in the project.
A clear definition of the project scope.

Are you using Playwright for automation testing? Run your Playwright test scripts instantly on 50+ browser/OS combinations using the LambdaTest cloud. Sign up for free!

Goals of Release Planning

Now that we know what release planning is all about, let’s continue and review some other goals that the business should aim to achieve when conducting a release planning session:

To identify any missing information that can influence the release.
To determine the release testing strategy.
To identify any technical limitation that must be addressed before the beginning of the first sprint.
Coordinate with development teams to synchronize their plans.
To get high-level estimations with story points.
Risk identification.
To identify project dependencies (external providers, other systems, etc.).
Synchronize all participants with critical epics and features that will be part of the project.
To agree on critical dates and milestones of the release.

The Agenda of Release Planning

The agenda of release planning and how to execute it can differ between organizations; there is no “one” way to do it that guarantees it will achieve its goals. However, there is one general (and very simple) process that you can use to run the meeting that can be good enough in the beginning and then improved. Let’s examine its different phases:

Phase 1: Presenting the Meeting agenda

In the first phase, the Product Owner (Or any other stakeholder) will review the meeting agenda, including its goals and the expected outcomes at the end of the session. To ensure that all the participants are familiar, it can be a good idea to perform a short cycle of introductions when there are new/external stakeholders.

Phase 2: Reviewing the release scope

In the second phase, the Product Owner (PO) should explicitly review the project scope and features that should be part of the release. In addition, this is usually when the PO provides a high-level description of the project roadmap (Including its key milestones), business urgency to deliver, and the product vision.

Phase 3: Reviewing the current project status

If it’s not the first release planning session, then previous work is already done. A good practice is to provide “high-level” information regarding the current progress and what has been achieved until now. In addition, the review usually contains the following data:

Feedback from various stakeholders on market conditions.
Expert opinions related to technical challenges.
Velocity from previous releases.
Technical Debt that must be addressed within the release timeframe.

A comprehensive end to end Testing tutorial that covers what E2E Testing is, its importance, benefits, and how to perform it with real-time examples.

Phase 4: Identifying risks and concerns

In this part of the meeting, engineering teams have the chance to present any risk, concerns, gaps, or any other issues that can influence the project release scope. Once all items are identified, there should be a mitigation plan and an owner to ensure it gets done.

Phase 5: Reviewing, updating, and defining critical artifacts of the process

This part of the meeting should be dedicated to reviewing, updating, and defining critical artifacts of the project (e.g., DoR, DoD, Available Resources, etc.).

Phase 6: Preparing a high-level plan

It is now time to start working on the release scope in detail. Once there is an agreement on features and stories that will be part of the release, it is time for the development teams and their Product Owners to start planning. Let’s look at some of the everyday activities related to this phase:

Teams should work with their Product Owner to discuss any non-functional stories they will need to deliver the release scope.
Teams will start determining their overall development and test strategy to meet the release scope.
Product owners will prioritize the team backlogs to meet the release scope and significant milestones.
Discussions are had between different teams to handle technical/project dependencies.

Phase 7: Confidence and commitment

This is the time for the teams to share their overall plan and to approve their commitments.

Phase 8: Meeting retrospective

A valuable practice in this meeting is to take the last 15 minutes and conduct a retrospective. The retrospective is concise and usually focused on a single question “How can we improve the next release planning session?”