Why do we need to plan releases? It would be great if we’d create a plan where everything works perfectly. And where the entire product is delivered as you imagined it would be.
But, in software development, things don’t happen this way, no matter how optimistic we are. That is why, with a good release strategy in place, you can ease out the entire release process.
The Agile release strategy is a product management method that allows us to release functionality in iterations. It’s easier to focus on short-term and repetitive iterations than on releasing large batches of work all at once.
In Scrum, often teams don’t plan the releases because the focus is on shorter sprints and many times they release the product increment. However, it can be done and it’s as useful as it is in other Agile frameworks.
1. What is agile release planning?
Agile release planning is a product management method where you plan incremental releases of a product. When we talk about releases in Agile, we consider the Epics and Features that we want to deliver.
The aim is to release the functionality described in Epics and Features in multiple stages. So how do we do this? We break down Epics into multiple iterations or sprints and we group the work and release it for the customers.
Let’s look at the table below for a better understanding.
What we see here is a typical release plan broken down by quarters. The plan contains the shipping cycles for this product. And what we observe here is how each release has its own Epic and Features.
- In Q1, we are planning to release Feature A and Feature B, which are part of Epic 1
- In Q2, we plan for Feature C, D and E to be released, but we continue to work on Feature B.1 and bring some improvements to what we shipped in Q1.
- In Q3, some of the work on Feature D, marked with D1, continues and we add Feature F to the release as well
- In Q4, we observe we can still improve Feature D so we get to Feature version D.2
This is how we structure frequent releases. We split the Epics into User Stories and then group them into Features. And we release entire or parts of the feature each quarter. However, note that each release must contain Features that bring value to the user.
This means that when we have a Feature that we work on for several quarters, each piece of the Feature that we release every quarter is usable.
Another thing worth mentioning is that it’s not mandatory to make a release to production after each sprint. At the end of a sprint, we aim to have a set of deliverables that can be shown and that bring value to the end product. But it is unnecessary to plan releases for every iteration.
One difference we see between release planning and sprint planning is duration. When we plan releases, we look at a larger time span that can go maybe up to one year.
But when we plan a sprint, we consider the work that needs to be completed in one, up to four weeks.
2. Traditional release planning vs Agile release planning
If in Agile release planning, our focus is on short periods of time, in traditional release planning, we focus on major releases. In Agile, we want to release functionality frequently and early, this way providing value throughout the entire process, not only at the end.
Below is a comparison between the two.
If we compare the two, we notice the following. The traditional approach is optimistic. We begin the journey by creating a plan that we think is going to work as expected, with no deviation. But we know already that in software development it’s not the case.
And while this approach has its benefits sometimes, other times we need to take an Agile approach. One where we encourage changes, we plan constantly as new information emerges. And also we rely on historical data when we make forecasts.
3. Why do we need release planning?
We need Release Planning because we have to make sure that progress is happening and we frequently release functionality to customers.
Releases are more granular than the product roadmap, so this way we ensure that pieces of the roadmap are made, in a logical manner, available to the end-users.
We have a timeline and scope much more defined than in the product roadmap, where everything is presented on a high-level scale.
Even if releases are more granular, they don’t outline each working item a team has to complete. But it groups multiple sprints, which are themselves more granular than releases, into several batches of logical functionality.
4. When should we plan releases?
When we have a large feature to work on, we won’t aim to finish the work at the end of one sprint and release it. Many features require more increments to complete.
That’s the reason we should group the work that spans multiple sprints. And this way release the work in batches by combining the deliverables of each sprint.
Another benefit of planning releases is that we don’t have to release an entire product at once.
Imagine you want to improve your customer’s experience with your product. So you decide you should rewrite half of its functionalities: Why we must consider multiple releases here?
- Customers are reluctant to big changes
- You can increase the ROI with early and frequent deliverables
- Test the market
The customers who are going to use your new product may fall into two categories. The ones that are already using the older version of your product. And the new ones that don’t know what the previous version looked like.
The first category of users won’t appreciate this radical change because they are used to how things worked before. And it’s easier and faster for them to use the product like that.
And releasing the product in chunks allows users not only to get used to the additional features and interface. You can also test the market with early and frequent releases. See what works and what you should stop investing time in.
Not least, during the entire process of developing the product, frequent releases of pieces of functionality can increase the ROI.
You are not delivering an entire product when it’s completely done and then earning (which can last more than you initially planned). You will earn from your product during the entire process of developing it.
5. Who has ownership over the release plan
In Agile, we find activities at all company levels; starting from the highest level, such as the company’s vision. And it goes to low-level activities, such as weekly and daily ones.
Every level supports the one above it. Changes are less frequent at high-level, and it shows instability and lack of vision when we see them happening too frequently at this level.
On a low level, it’s usual to see things changing often, as long as these changes support the level above.
Executive leaders, departmental leaders, and architects develop the higher levels. They are developing the company vision and business strategy.
The product manager, product owners, and customer advocates are creating the product strategy and roadmap, and are planning for the release dates. In Scrum, this falls under the Product Owner’s responsibility.
It also involves the implementation team in planning the releases together with the product manager and product owner. But also in planning each iteration and the daily plan. In Scrum, the entire Scrum Team does this.
6. How can you create a release plan
There are a few things that are necessary for you to have to create an accurate release plan:
- An accurate release plan requires a prioritized and estimated backlog
- You need to know what is the velocity of your team
- Work together with your team and put some effort to your User Stories
- Group the User Stories in Features and decide the order for releasing those batches
A release plan is derived from the backlog. We need an organized backlog that clearly describes what the team should accomplish. Only this way a release plan can reflect the reality of what the team and organization can deliver.
Another thing that’s absolutely required is the team’s velocity. Velocity is the measure of work that a team can produce over time. If we don’t know how fast can we go, we cannot know when we are going to get the work done.
We know that our team’s velocity is 20 SP and that we work in two weeks iterations. Now we can say easily that “Requirement I” will be delivered in the fourth iteration. And because we work in 2 weeks iterations, “Requirement I” will be delivered in 2 months.
Over time, the velocity of our team can vary. It can have some high and some low points. So we can make a forecast based on several scenarios.
Let’s look at the example below to see how we can use velocity
Looking at the requirements above, the total cost is 73 SP. Let’s see what forecasts can we make.
Say that the highest velocity the team had over time in one sprint is 40 SP and the lowest is 15 SP.
- Best case scenario based on the highest points per sprint: 40 SP
- Estimated delivery of product 1 month = 2 Sprints
- Most likely scenario based on the average between 40 and 15: ~28 SP
- Estimated delivery of product 1 month and a half = 3 Sprints
- Worst case scenario based on the lowest points per sprint: 15 SP
- Estimated delivery of product 2 months and a half = 5 Sprints
Final thoughts
Creating a release plan is not too difficult, but you need a couple of things prepared before you do that. Don’t forget that this is work for the entire team, and the responsibility of the process is shared between the Product Owner and the Developers. If you have any thoughts on this, please leave a comment below.
