What is Agile release planning & how to do it

I’ll reveal all my cards right away – planning is crucial for agile engagements. As you’ll soon learn, it’s hard (if not impossible) to stay agile without some planning. Whether it’s for a sprint, a release, or an entire product, the sense of direction it gives your team is invaluable.

And if you need further proof, Planning Poker is a popular estimation and planning technique for agile.

Let’s unwrap why agile doesn’t mean “no planning”, how to plan a release in agile, and more.

What is an agile release?

A release is a set of features which can be published regardless of work that hasn’t been done yet.

You can also reframe that in the simplest terms as the latest version of the software.

If you want to get a bit more technical, I like thinking of a release as a complete, independent piece of code that isn’t blocked by any outstanding tasks and satisfies the MVP requirements of the stakeholders. But let’s keep it simple.

Releases come in a variety of sizes. I won’t bore you with the details, but it’s useful to point out that a release can be as simple as a 5-minute bug fix, or as complex as a major deployment of the first version of a website or software application. For the sake of simplicity, let’s call them “minor” and “major”.

Public vs private software releases

A release can be public, which means it’s available to see for all your users. Those users are sometimes described as “live users”, “live traffic”, or “live audience”.

On the other hand, a private release is available only to the development team and stakeholders. In our case, we prefer to have three website environments:

• A development website which is only for the eyes of the development team and is, generally, a controlled mess
• A staging website where the stakeholders can preview new releases and experiment with content changes
• A live website which is what it says on the tin – an environment accessible to the public

The first two environments are where the private releases happen. We could get into more detail regarding categorising release types, but you won’t need it for the purpose of this article.

Examples of an agile release

There’s a myriad of ways you can visualise and communicate a release plan in agile. Here are a few screenshots from our favourite tools:

What do you need to plan a release in agile?

Here’s the key information you need to plan a release:

• An up-to-date list of user stories and tasks
• Story point estimates
• Priorities of stakeholders
• Definition of done for user stories and tasks

Let’s discover what they all mean.

What are user stories?

In some of the agile release plan examples above, you’ve encountered “features”. Ultimately, the features are written down as user stories instead.

A user story is an informal way of phrasing a feature from the perspective of the end-user. It consists of an actor, the story itself, and an outcome. There are a few ways to formulate them, but one option would go something like this:

As a user, I want to read an article about agile release planning so that I can learn about the benefits of agile for web development.

Why do user story estimates matter for agile planning?

We already know that the size of a release can vary. Just to recall, a major release usually spans multiple sprints, while there could be several minor releases in a single iteration. But those iterations don’t appear out of thin air. They’re possible thanks to two, sometimes three parameters of user stories:

• The estimate
• The priority
• The value to the client

Our team only uses the first two. We’ve found that people are more efficient when they focus on priority alone. You probably won’t be surprised to find that they often relate priority directly to the value anyway. We thought that introducing another parameter to an already abstract and confusing concept isn’t a good idea.

Once we know the complexity estimate and the priority, we can mix that with the technical knowledge of the development team to create a roadmap. Our team adds a few more considerations to the mix, such as the velocity and dependencies between stories. The outcome is a release plan that delivers the most value first.

What is a release plan backlog?

In the introduction I’ve mentioned that agile is about continuous improvement, so you might already know where this is going. During sprints, tasks fly left and right. Priorities change, new requirements arise, and old feature requests are scrapped. It’s only natural that it is this way – businesses change all the time, and web development should be flexible to accommodate those changes.

It’s a good practice to look at backlog at different levels. I’ve already outlined three obvious ones above – product, release and sprint. Even though they’re similar by definition, there’s one key difference. A sprint backlog is always fully estimated and prioritised. On the other hand, the product and release backlogs can often be more of a “work in progress”.

There might be new tasks that need to be estimated and prioritised. This can sometimes force a change in the release plan. Adding a new user story with a big estimation will naturally stretch it while removing or de-prioritising an existing large story could expedite the next release.

One of the big backlog red flags is when agencies tell you that you can’t change the sprint backlog mid-iteration.

That’s a myth and goes against agile principles. If there’s value, you can add and remove tasks from the backlog of an active sprint. The only definitive “no” here is starting an iteration with an incomplete sprint backlog – if you’re missing estimates or “definition of done” for some user stories, you should remove them before starting the sprint.

What is the release planning meeting and why is it needed?

Release planning, as with almost everything in agile, is a collaboration between multiple scrum team personas. The scope and complexity of the meeting far exceeded the capabilities of an individual.

There’s some flexibility as to how to run the meeting, but here are two prerequisites:

• Make sure the Product Owner knows the priorities of stakeholders inside out
• Have a good idea about the product vision and the high-level goals

Naturally, you would have estimated the tasks by this point. Stakeholders like prioritising tasks knowing their complexity. It allows them to put everything in context and find the right balance between perceived priorities, complexity and actual value. And agile is all about delivering value as fast as possible, so it all ties together.

The primary purpose of release planning in agile

Equipped with all the knowledge you need, the team sits down to plan releases (and usually the first sprint). At this point, you’ll take the product vision and goals into account to split them into more attainable objectives – sprint goals.

You don’t have to go all-out. It’s still agile, and we’re doing things as and when needed. But setting a goal for the first couple of sprints shouldn’t be excessive at this stage. It helps the team understand the upcoming iterations.

It also helps you set clear expectations internally and externally. Communication is key in agile, so that little bit of extra knowledge goes a long way with stakeholders.

Without a release plan, you’re not agile. It’s that simple. It’s impossible to deliver value as early as possible by just winging it. And you get all the benefits I described above as a bonus. It’s a no–brainer.

Who should attend the release planning meeting?

The release planning meeting includes the scrum master, product owner and the development team. Stakeholders are not present at this meeting – by the time a release is planned, the product owner should have all of the information from stakeholders, as outlined in the prerequisites above.

It might be counterintuitive for you to be excluded from release planning as a stakeholder, but it goes into much more technical details. Third-party input isn’t required at this stage.

Agile release planning activities

To create a good release plan, the scrum team needs to do the following:

• Make sure the outstanding tasks are complete (i.e. they have story point estimates and the definition of done) and the stakeholders’ priorities are known
• Identify dependencies between user stories and tasks
• Re-prioritise some features based on the above
• Note down any questions to the stakeholders that arise, i.e. suggest ways to reduce the complexity of some features or improvements that would help with the user experience
• Split the tasks into releases
• Take the velocity into the account to estimate the number of sprints needed for the release
• Communicate necessary findings to the stakeholders to see if their input is needed, i.e. ask for approval to simplify some tasks

High-level and detailed release planning

We’ve mentioned that release plans come in different sizes. For some stakeholders, an MVP is all they need and the project necessitates only a single major and public release. Here, a high-level plan will suffice.

This is a bit different for live products. As an example, you can go about redesigning a blog by having multiple smaller iterations:

1. Releasing the new blog article template
2. Releasing the new blog categories
3. Releasing the new blog index and pagination templates

You can be more detailed or superficial, but you’re never limited to an all-or-nothing approach. If you have a finished piece of code that adds value, why wouldn’t you release it to the live audience? The sooner you get feedback, the faster you can address it.

Frequent releases require more detailed (and more frequent, duh) release planning, but I hope I’ve convinced you that it’s not a downside at this point.

When should you hold the release planning meeting, and how long does it last?

Release plans take longer than sprint planning – partially because the former makes the latter easier. Where sprint planning could take just a couple of hours, a full product plan can last a day or two.

It sounds like a lot, but that work has a huge ripple effect on an agile engagement. It gives you a good basis for sprint planning, as mentioned, but also allows you to keep the backlog in check.

For web design projects, release planning usually takes up to six hours – with a couple of sessions with the client during the day.

In our workflow, initial release planning happens on the first day of the first sprint. Subsequent planning sessions happen at the end of each sprint, after a sprint review session with the stakeholders. I think you know why it’s in that order, but if not, here’s a little reminder – we need to establish priorities with the stakeholders, and that happens during the sprint review.

How often do you plan releases?

Your backlog is a living entity. It will change often, perhaps multiple times a sprint, or more than once a day! We’ve already teased this section above – our release plans happen once a sprint, with an additional meeting at the start of the first sprint.

In reality, it could be more or less often. There’s no rule of thumb. Welcome to agile. If your requirements change, we act accordingly. So the final answer is to host release planning meetings whenever cumulative backlog changes necessitate it.

How do you maintain transparency with release planning?

It all comes down to one of the agile principles – communication over documentation. As a stakeholder, it’s understandable to be a little reserved when release planning happens without you.

In this article, I’ve explained why that’s the case and why it’s not a bad thing. But if you still have reservations about it, here’s the summary:

• The entire legwork leading up to release planning is done with you involved in the process. If everything goes well up to that point, the scrum team will be well-equipped to create a plan.
• Release planning is a highly technical process which includes details about programming complexity, code and design dependencies, and more. It’s an internal meeting of the agency you’re working with, so there’s nothing to worry about, even if the name of the process gives you a hint that you should be included in it.
• Communication is key. Release planning isn’t “one and done”, and you’re not excluded from its findings. You will know the outcome of the meeting and the flexibility of agile makes it easy to change things around.
• You’ll have several occasions to give feedback on the release plan. We’ve mentioned that you can have several release planning meetings per iteration if the requirements change. Whenever you feel that the team is going in the wrong direction, or that it’s going in a direction you know nothing about, ask them to have a brief review and you’ll get back on track.

Roadmap vs. release plan vs. sprint plan

What is the difference between a roadmap, a release plan, and a sprint plan? We’ve touched upon this through the article and you might’ve picked up some of the differences, but let’s briefly summarise it.

A product roadmap is a high-level summary of the requirements. Stakeholders have the most ownership of this one. It’s your entire product vision, unleashed. There are little to no technical constraints just yet. You could say it’s the first draft.

A release plan is quite different from the get-go. It’s an internal tool of the scrum team. In the context of the entire project, it’s still a high-level overview. But it’s also more refined than a product roadmap. Some of the requirements are already estimated and prioritised, they might even have a clear definition of done.

The sprint plan completes the trinity. It’s much more hands-on. Developers add acceptance criteria to it, which dictate how the feature should be implemented. Everything is estimated, prioritised and defined to ensure the development team can deliver value as soon as possible.

Agile release planning tools

You shouldn’t be surprised if I say that it’s extremely flexible. Anything that works for your team is acceptable. In the end, the features will end up in a project management software like Jira. This isn’t a friendly environment for a stakeholder, though.

We love using Miro for release planning. In fact, any digital whiteboard tool will work. And as you’ve seen above, we can even plan a release on an actual, physical whiteboard. Sticky notes for life.

If you can’t live without spreadsheets, be my guest. It’s not the best solution for long-term changes, but we’ve seen it work for some companies.

Anything works as long as you can somewhat easily move things around and group them into releases and sprints.

How to plan a release using the Miro template

When you open the template, you’ll see that there are three cards that you’re going to use:

1. An activity card
2. A task card
3. A user story (or feature)

The cards are ordered this way for a reason – they create a funnel. Your activity cards will be the broadest, while a user story is more detailed. Here’s how to fill them with the key details.

What is an activity in User Story Mapping?

An activity card only needs a title. That’s it. You can think about an activity as the goal of the user.

Managing an account would be an excellent example of an activity.

How to understand tasks in User Story Mapping

You’re probably filling the gaps yourself, but tasks are the smaller bits the user has to do to manage an account. First, they have to “log in”. Then they’ll need to navigate to the appropriate section of their account, so your next task could be “change a password” or “view order history”.

If you think that’s easy and natural, that’s the point! This is the greatest strength of agile. Everything revolves around the user, and when you split things like that, you’re less likely to miss the key details.

How to map user stories

Finally, we get to user stories. As you know, this is the most detailed and the most technical part.

First of all, you’ll follow the pattern of “As a user, I want … so that …”. Easy.

Then you have the priorities. This should be communicated by stakeholders to the Product Owner. So far so good.

Next, you’ll need an estimate of story points. That only concerns the development team, though. Just remember a story point is a matter of relative complexity. If you take writing (the one with the pen) as an example, writing a capital “O” would have a complexity of one – it’s just a circle. Writing an “H” is obviously more complex, and you estimate it compared to the complexity of “O”.

Last but not least, you need a definition of done. This is a user-centric description of what the user can do.

Following on our example of a task to change a password, you could have two user stories for that:

• As a user, I want to change my password so that I can keep my account safe
• As a user, I want to get a notification about my change of password so that I can verify that I haven’t been hacked

Let’s consider the former. The definition of done would look as follows:

• User can input the current password
• User can input the new password
• User can confirm the new password
• User can submit the form to update the password
• User can see error messages if the form has mistakes

You can see that we’re not concerned with technicalities yet, such as the validation of the fields (how many special characters to include, the length of the password, etc.) These belong to the acceptance criteria, which developers write as and when needed – usually during a sprint.

Team effort is crucial when it comes to release planning in agile

We’ve learned that a release plan doesn’t appear out of thin air. At the same time, too many cooks spoil the broth.

The process involves everyone, from developers to stakeholders. But the release planning meeting itself is an internal tool of the scrum team – so your web agency or a software house.

Even though planning a product without its stakeholders might seem like a bad idea at first, we shouldn’t look at “release sprint planning” in the traditional fashion. If you’re a stakeholder in the process, don’t worry, you’re not being excluded.

And if you’re a part of the scrum team, take the above into consideration and help stakeholders ease into the process. Perhaps this article can prove to be helpful, and you can use it to explain the subtlety of release planning to your customers.

So what do you think? Does this sound better than the lengthy website briefs when working in the traditional way? I hope so! Let’s discuss in the comments.