Are you wondering why it’s important to make a release plan, when to do it, who should participate in it, how to build and update it, and what practical tips to consider? In this article, we will answer all these questions in a simple and straightforward way. We’ll even give you some concrete examples so you can understand how it works. So, let’s get started!
Before diving into the Release Plan, it’s important to understand the difference between the Release Plan and the Roadmap, as they are two distinct concepts that should not be confused.
Attention !
Release Plan is not the Road Map
Roadmap
- The roadmap is a longer-term strategic vision of the project or product. It identifies key phases, goals, milestones, and planned features for the project over an extended period of time.
- It can cover multiple versions of the product and can even span several years.
- The roadmap usually doesn’t specify the details of each iteration or version of the product, but rather outlines the vision to be achieved.
Release Plan
- The Release Plan is a shorter-term planning that focuses on the specific delivery of a product release at a given point in time.
- It often stems from the roadmap, identifying which features or elements of the product will be included in each version of the product.
- The Release Plan is more operational and detailed than the Roadmap, as it takes into account specific iterations (sprints).
WHY MAKE A RELEASE PLAN
The Release Plan is an important element in the agile framework for a number of reasons:
Sprint Planning
The Release Plan allows the project to be divided into Sprints, short and focused development periods, where “User Stories” are concretely realized.
Communication of Objectives
The Release Plan ensures clear communication of the project’s goals to team members, ensuring that everyone understands the “User Stories” and “Epics” to be made.
Alignment with Vision
The Release Plan ensures that the team works in alignment with the product’s vision, choosing the “User Stories” that contribute the most to that vision.
Dependency Management
It identifies dependencies between “User Stories” and “Epics”, helping to organize work in a way that resolves these dependencies in an efficient manner.
Prioritization of User Stories / Epics
The Release Plan helps prioritize features (User Story) and “Epics”, i.e. broader sets of features, based on their value to users and the time it takes to develop them.
Risk Management
The Release Plan helps manage risks by identifying dependencies between User Stories and planning Sprints accordingly.
Representation of Milestones
The Release Plan represents the major and necessary milestones in the life of the product and the project, allowing the team to focus on the crucial steps for success.
WHEN TO MAKE A RELEASE PLAN
The ideal time to create a release plan is when you have a clear vision, a list of priority items, an understanding of constraints, and stakeholder involvement.
Frequency
Throughout the project: Sprint 0, at every Product Backlog Review, at every Sprint Review
1
Duration
- 2 to 4 hours of preparation
- 2 to 4 hours of workshop
- 1 hour update
2
Inputs
- Up-to-date Product Backlog
- Estimation of User Stories (a macro estimation may be sufficient)
- Story Map and Impact Map (if applicable)
3
Outputs
- At each Product Backlog Review: modify the Release Plan if User Stories are modified (addition / deletion / new estimate)
- At each Sprint Review: modify the Release Plan according to the team’s Velocity.
4
Frequency
Throughout the project: Sprint 0, at every Product Backlog Review, at every Sprint Review
1
Duration
- 2 to 4 hours of preparation
- 2 to 4 hours of workshop
- 1 hour update
2
Inputs
- Up-to-date Product Backlog
- Estimation of User Stories (a macro estimation may be sufficient)
- Story Map and Impact Map (if applicable)
3
Outputs
- At each Product Backlog Review: modify the Release Plan if User Stories are modified (addition / deletion / new estimate)
- At each Sprint Review: modify the Release Plan according to the team’s Velocity
4
Who Participates in the Development of a Release Plan
The participation of the stakeholders below ensures balanced planning, aligned with the product vision and taking into account the needs of the end users and the constraints of the project.
Product Owner
Responsible for prioritizing and managing the Product Backlog. It plays a central role in the creation of the Release Plan.
Stakeholders
Including sponsors, end-users and other stakeholders, are consulted for information on needs and expectations. Their feedback influences feature prioritization.
Development Team
Actively participates in the development of the Release Plan by providing complexity and time estimates for User Stories and contributing to planning.
Scrum Master
Facilitates the planning process and ensures that the team follows the principles and practices of Scrum or the chosen agile methodology.
Architect / Technical Expert
Can give macro estimates during the session.
Indicates the technical dependencies between items.
Can provide the technical elements necessary for planning (Technical Debt, cross-functional projects, etc.)
Quality Manager
Ensures quality by identifying the necessary tests for each feature and for the entire product.
HOW TO BUILD AND UPDATE A RELEASE PLAN
Before starting the development of the release plan, it is essential to check the availability of the following prerequisites :
Project Vision and Objectives
It’s essential to have a clear vision of the project and its goals before you start planning for feature delivery.
Established roadmap
The Roadmap, which sets the overall direction of the project over a longer period of time, often serves as the basis for creating the Release Plan.
Prioritized list of items
You should have a list of deliverables, such as User Stories or Epics, that have been prioritized based on their value.
Understanding Constraints
It’s important to understand project constraints, such as deadlines, available resources, and dependencies between items.
Stakeholder Involvement
The involvement of stakeholders, including the development team and sponsors, is necessary to ensure that the Release Plan is realistic and aligned with expectations.
Known timeline
It’s often helpful to have an idea of the target timelines or dates when product releases need to be delivered.
Once the prerequisites have been confirmed, it is important to structure your work into three phases:
1-Initial Preparation
- Allow about 2 to 4 hours
- Identify the Epics or User Stories of the next project Releases
- Perform a macro-estimation
- Prepare feature sticky notes (use post-it colors to illustrate domains or others)
- Prepare the Project Timeline: Sprints, important milestones, etc.
2- Workshop to create the Release Plan
- Allow about 2 to 4 hours
- The Product Owner places the sticky notes directly on the wall to prioritize them within each Sprint
- While respecting constraints (Sprints, dependencies and production capacity)
- Everyone participates freely in the workshop
- The Scrum Master and the Dev Team estimate a projected production capacity.
3- Workshop to update the Release Plan
- Allow about 1 hour
- The Scrum Master provides the Product Owner with all the updated information (backlog items, team velocity)
- The Product Owner updates the Product Backlog based on velocity information and dependencies.
RECOMMENDATIONS
Prepare well for this workshop: especially the first one!
- It’s easier to work with Epics or groupings of User Stories at first (less post-it notes to manipulate & clearer information)
Time Box
- Meet the workshop deadline: it is always possible to work on the Roadmap after the workshop.
Space
- Favor a large room accessible to all for better sharing of information with all teams
Milestones
- Identify the milestones and business challenges of the project (Pilot, production and Go-Live dates)
- Identify technical dependencies and “cut-out” macro-features
Remote team
- Do the work at the Product Owner’s premises.
- Share the results simply with a photo and replicate the prioritizations in JIRA.
Participatory method
- The Product Owner is responsible for prioritization within Releases, but everyone must participate freely in order to have a shared Release Plan
For remote teams, it is also possible to have a representation of the Release Plan In another format: PPT or Excel. The point is to have a macro view of the project with the main dependencies and milestones
0 Comments