Planning Releases & Sprints In Scrum – A Beginner’s Guide

The purpose of release planning is to deliver in production, at certain intervals, the features we develop to make them available to users.

Each release contains part of the final product that we can deliver and customers can use.

Incremental releases allow us to gather feedback after each release so that we can see how the functionality is being used. This helps us decide what the next releases will look like. 

The purpose of sprint planning is to define what we can deliver within a sprint. Each sprint will contain part of the functionality planned for a release. 

It is not mandatory to release functionality in production after each sprint, but you still have to make sure that the work is potentially releasable. This means you have a working functionality that you can release anytime you want.  

But to plan releases and sprints, you need a Product Backlog based on new ideas. The Product Backlog relies on business innovation and team collaboration. 

Here is a very simple representation. 

Release planning

Step #1 Prioritize the Product Backlog

The first thing you’ll need to get started is a prioritized Product Backlog. To obtain it, you have to create an ordered list of epics that represents functionality you might deliver at a certain point. 

The epics should be well described because they represent the baseline of the conversation you will have with the rest of the team. However, the level of information in each one of them should differ depending on the priority of each epic. 

The ones that are at the top of the list will contain more information, while the ones at the bottom will have only some high-level details. The reason is that the market changes and you might have to drop some of the features you initially thought of. 

Step #2 Hold a workshop session

Once you have this list, before going to the workshop, you will want to identify the key features, which will be your epics, and also some user stories. The epics that are top of your list would be the ones you need to meet your first release goal.

I aim for a 4 hours workshop when I first bring in a new product. One reason is that I present the entire initial plan to the team before starting the activities. 

The activities for this workshop are: 

• Collaborating with the team to identify if there are more epics or user stories to be added
• Estimating the resulting user stories
• Prioritizing them

After estimating and breaking down enough items for approximately two sprints, I want to get a high-level estimation for the rest of the work that is planned for the first release. 

This is to see how much time it would take for the first release to happen. If I have a deadline, this helps me reduce the scope and talk with the stakeholders. 

Once you have all this information, you can start thinking about what date would be attainable for the first release. Don’t plan all the releases from the beginning. Things will change from one release to another based on what the team learns during development, and from the feedback they get. 

The user stories you prepare before the workshop don’t need to have all the details. Just enough for the team to understand what’s required and feel comfortable estimating. 

There will be questions your team will address during this session. You can answer some of them on the spot, but for some, you might need to do a little research. So you can gather all the information by the time you’ll have your refinement session.

After this workshop, to prepare for the sprints to come in my first release, I work with the team in the refinement sessions. Here, we have the same activities as in the workshop, but more focused on the epics we haven’t yet broken down during the workshop. 

I will hold the next workshop only when it’s time to prepare for the second release. 

At end of the workshop, you’ll have a backlog that looks like this:

• Estimated and prioritized user stories at the top of the list, enough for the next two sprints
• High-level estimations for the rest of the work (epics or user stories) planned for the first release
• Epics for long-term objectives
  
  If you need to, you can also do a little planning during the workshop. For example, if this is your first sprint with a new team, you can plan some items for the team to work on.  

 Step #3 Gather all the relevant people in the release planning

• The Product Owner, who brings a prioritized list of work items at an epic or user story level
• The development team estimates, and helps with prioritization or identifies more possibilities to breaking down an epic
• The Scrum Master who facilitates the discussions and makes sure Scrum practices are being applied

Sprint planning

Before any work begins, you need to hold the sprint planning session. But you cannot have sprint planning without enough information on the user stories the team should work on.

Step #1 Plan your sprint

Earlier in your release planning workshop, you prioritized and estimated approximately work for 2 sprints of your first release.

In the meantime, you have also updated the user stories with some low-level details and discussed them in the refinement session preceding planning. 

Preferably, you allow the team to come up with additions regarding acceptance criteria in refinements if requested. These might slightly change some estimations too. 

Now that you have all the prerequisites, the development team can select several user stories they are feeling confident they can deliver by the end of the sprint. 

While working on these user stories, you’ll see there will be more than you and the team identified during development. Take them into consideration in your future sprint planning sessions if they are important items for your release. 

Important to mention is that is not mandatory to release functionality after each sprint and releases can happen after several sprints. 

Step #2 Find the right time to fit the workshop within the sprint

There are two ways you can incorporate the release planning workshop into a sprint.

1. When this is the first sprint you and your team work together on a new project

It can be challenging to have enough work prepared for the development team for their first sprint. Especially when you are working in a company where all the teams have the same sprint start and end date.

Your collaboration with a new team may start on the very first day of the sprint, or at any other moment.

But a team that doesn’t work for days, waiting after a sprint backlog, is counterproductive. 

So, to increase efficiency, what I do in these cases is this: 

• If we start on the first day of the sprint, I replace the planning session with the workshop but do also a little planning, as I mentioned earlier
• If we start on any other day, I also book 4 hours for the workshop and plan some work for the rest of the sprint 
• In both cases, I’m using the refinement session to prepare further for the upcoming sprints

2. When there is an ongoing project for you and your team

This is easier to manage because, in the last sprint of the last release, you can use the refinement session to hold the workshop for the next project. 

This allows you to begin a sprint where you use the entire velocity of your team for development and their usual activities.

How the release planning and sprint planning work together

To simplify the example, I will talk about a real-life situation non-related to software development. 

Imagine you buy a house and you have to furnish it. Furnishing your entire house is the end goal of this project. 

You decide what are the most important elements you want to add first to your home, depending on the importance and use of each one of the rooms. So you’ll have a list of prioritized epics forming your backlog. 

Let’s say the most important epics are the bedroom, the bathroom, and your kitchen, in this order. This is what you need to start with to feel somewhat comfortable. This is what you want for your first release.

But you assess that the first two are vital for you to move in, so you try to identify what are the most important pieces of furniture you need there first. You also have to add some characteristics of that furniture at this point. These will be the user stories you create. 

Next, you meet with your team and you present them with the vision and the goal of the project. 

The team can help you at this point to identify more user stories for the first two epics. They estimate them and take part in the user story prioritization. 

After you identified the work for your next two sprints, you might end up with some use stories that won’t fit in this interval. But you can ask your team to give you a high-level estimate for them as well as for any other epic that is left for the first release. In this case, the kitchen.

Note that any release can contain a combination of user stories from different epics. Here, you don’t have to furnish completely the bedroom before the bathroom. You can combine the most important pieces from both and make those a priority. 

You now have enough details to make a prediction of when the first release date could be. 

Before you plan your first sprint, you will probably need to update some of the user stories with more details. Discuss the updates in the refinement session following the workshop and see if any estimations will change or you have to add more acceptance criteria. 

And you should be ready for the planning. You will only need to choose the right amount of work for the sprint, add some subtasks and let people assign user stories to themselves.  

This is how I organize my workshops within a sprint

If I work with a new team on a new project, I will hold the first workshop instead of the planning session.

 If we start a new project after completing a previous one, I hold the workshop in the middle of the sprint. This will allow me to prepare any answers needed by the time we meet for the refinement.