How to Make an Agile Release Plan, With Examples

"Change is the only constant in life" - Heraclitus

Was Heraclitus a developer, or did the Oracle of Delphi show him where things were going? Either way, his most famous quote is an apt description of the world we work in. We have to navigate constant transitions while maintaining forward progress. The Agile process helps us cope with that chaos. It's right there in the name: having a quick, resourceful, and adaptable character. So when it's time to plan the first or next increment in your product, you need an Agile release plan. 

Let's look at what an Agile release plan is and how you can go about creating one. 

What's an Agile Release Plan?

Many bloggers have spilled a great deal of digital ink over the topic of Agile, where it comes from, and how to implement it. But we have the Agile Principles. They're the essential guide on what it means and why we need it. So, before we delve into creating an Agile release plan, let's level set. 

The Agile Principles

 cover the four principles and how they relate to an agile release plan. 

#1 - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Any successful software development team focuses on customer satisfaction, but this principle introduces the concepts of early and continuous. 

Early and continuous means releasing features and fixes as you build and test. It's Agile's alternative to holding onto new code or rushing new features in the service of meeting an arbitrary date. 

#2 - Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Here's the hard part. Your release plan needs to keep your development efforts on target, but you still need to address changing requirements. 

#3 - Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Principle #3 echoes the salient points in #1 but helps us out by establishing a solid time range. Agile works in increments of weeks. 

#4 - Business people and developers must work together daily throughout the project.

Finally, we get a hint on how to formulate and execute an Agile release plan; by getting developers and business people to work together. Moreover, they don't work together on the project and head back to their respective departments. They work together daily. 

Before we move on, it's worth paying Principle #6 a brief visit. It refines and reinforces #4 when it calls face-to-face conversations the most effective form of communication. You don't do Agile Release Planning over emails and Jira tickets. You do it by sitting down as a group and formulating a plan. 

What's an Agile Release?

Based on the Agile principles, we can infer what makes a release agile. A release is a set of features you deliver to customers in a single increment. It's agile when you bake in the ability to adjust. 

Agile release plans adapt to changing requirements and conditions. They don't pick a date and decide what fits in or set a date and drive mercilessly to meet it. They set priorities, estimate the effort required, do the work, and make adjustments based on updated conditions and results. 

Agile Release Planning Process

The release planning process helps your team determine how to channel their efforts into the next increment of features and fixes. 

Step 1: Establish the Release Vision

Before planning a release, you need a vision for your product and its next step. This vision guides you as you decide which features to prioritize, which to slip if the situation changes, and which to set aside for the next pass. 

This is the first step in the process and the first opportunity for business people and developers to collaborate. The release vision must align with business goals, market conditions, and engineering reality. 

Step 2: Evaluate Your Backlog

Now, it's time to look at your product backlog and sort the features by priority. This is where you put your vision to work. 

Here again, everyone is involved; engineers and stakeholders apply a shared vision to the product backlog and product roadmap to determine what the priorities are for your product. 

Finally, create a basic release plan that outlines the goal, a target release date, and a complete set of ranked user stories with story points. This is the output you'll need for the next step. 

Step 3: Review the Agile Release Plan

Next, take your draft release plan, assemble all stakeholders, and hold a release planning session. Developers hate meetings, but this one is essential. As we covered above, Agile places great importance on face-to-face interaction and alignment between the business and engineering. This meeting will ensure that everyone understands and agrees with the plan.

The meeting agenda should cover the following items. 

Review Roadmap

Review the vision and the product roadmap. If it seems like these steps include a lot of repetition and review, that means you're paying attention! This is another opportunity to ensure that the stakeholders are on the same page regarding the product and the release. 

Review Design and Architecture

Next, review the technical details and design for the release. Are there dependencies or gaps that can affect the release schedule? How will the plan be adjusted if these issues can't be overcome? 

Review Iteration schedule

The draft release plan has user stories, story points, and proposed sprints. This step takes those stories and arranges them into sprints. One method is to arrange the stories into sprints based on velocity. How much can you reasonably expect to get done in each sprint based on development resources the points assigned to each story? 

Define "Done"

What does "done" mean? Do the stakeholders and the developers agree on what the completed release will look and act like? This is where the Definition of Done needs to be codified by all stakeholders. 

Step 4: Execute and Update

Finally, it's time to execute the plan. Agile release plans are living documents, so putting them into action is part of the planning process. 

A review follows each iteration. What went wrong? What went better than expected? These inputs are critical for planning the next sprint. This step is crucial in keeping your development efforts on track. 

Agile Release Plan Examples

Let's finish up by looking at how to apply this process to the two most common product release scenarios. 

New Release

When you're planning a new release of an existing product, you already have a lot of information. There are few things more valuable than "we've seen this before" when planning and adjusting an Agile release plan! 

There's already a product out there in the world, which means someone had a vision for what it should do. It may not have been formally recorded or discussed, but there's something there. Now is your chance to get everyone together and make sure the current vision is in harmony with market conditions and business needs. Then, you can either update or create your roadmap and your design. 

The previous releases mean data on current efforts and timelines. You might be new to Agile, but you know how long the last release took and how long it takes to turn around a bug fix. That's all valuable input to the process. 

Finally, the success or failure of previous releases will be a valuable guide when getting the stakeholders together to define "Done." 

New Product

When planning the first release for a new product, you have to rely on the team's collective experience combined with data gathered in the testing and prototyping stages. (Of course, those stages should have gone through this process, too?) Maybe you're planning one of those stages and have nothing to go by. 

It's hard to say that there's a most critical step of the plan, but if it exists, it's the vision, especially when talking about a new product! If the interested parties can't agree on what the new product will be, how can you define the effort required to build it? How can you define "Done?" 

Once you've agreed on the vision, you're going to do a lot of estimating and a lot of adjusting. That's okay! The estimating and adjustment are features, not bugs. 

Start Your Agile Release Plan

This post covered what an Agile release plan is and how to create one. We started with first principles (or at least a subset) and applied them to planning and executing a release. Then we wrapped up with an overview of two common release scenarios. 

Get started with your next Agile Release now!