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 much more.
Let’s start at the very beginning. 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”.
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:
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.
When comparing agile to waterfall, you’ll notice that there are usually many more releases in agile projects. In our experience, websites built with the waterfall methodology can have as little as a single public release on the date of going live. On the contrary, our agile sprints tend to have multiple minor, public releases each week.
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:
Here’s the key information you need to plan a release:
Let’s discover what they all mean.
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.
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:
Our team only uses the first two. We’ve found that people are more efficient when they focus on the 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.
Includes tools to maximise your website potential.
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.
When referring to a release backlog, a product backlog or a sprint backlog, we’re really talking about a list of outstanding user stories, tasks, improvements and bugs.
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.
Release planning, as 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:
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, the complexity and actual value. And agile is all about delivering value as fast as possible, so it all ties together.
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.
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.
To create a good release plan, the scrum team needs to do the following:
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:
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.
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.
We hate the “it depends” answer, but this is the case here. The extent of a release plan is solely at the discretion of the stakeholders. And more often than not, they’ll be eager to have a detailed plan – even if it’s just an estimate.
We’ve already established that planning the entire product upfront is usually a good idea, so it’s a win/win – as long as you stay true to agile. The release plan will be rough around the edges because that’s where sprint planning and sprint reviews come in to refine it. You don’t have to be perfect with your plans.
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.
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:
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.
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.
User Story Mapping is our favourite framework for planning agile releases. That’s exactly what our screenshots and pictures above show. If you’re looking for a template, we highly recommend the one from Miro.
When you open the template, you’ll see that there are three cards that you’re going to use:
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.
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.
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 very 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.
Finally, we get to user stories. You know quite a bit about them by now, but let’s quickly recap the minimum requirements for creating good 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:
Let’s consider the former. The definition of done would look as follows:
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.
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, make sure to 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.
Includes tools to maximise your website potential.
Originally published May 25, 2022 4:16:29 PM, updated June 23 2022.