In project planning, business stakeholders often ask development teams to predict the future and answer tough questions like: 

• What features will be included in the final product? 
• How long will it take to develop all or at least the most valuable features?
• What will the team have completed by X date?
• How much will it all cost? 

Using Release Planning with an iterative development process, teams can better plan the future and answer these key questions. By creating an outline that incorporates the steps needed to develop a product as a high-level map of releases, the number of sprints required for each release, and alignment of the work items or features being developed in each sprint, this will assist in creating an understanding for how the product will be shaped into different product iterations multiple sprints into the future. 

How to Create a Release Plan 

Creating a release plan requires three (3) main steps:  a product backlog where work items are prioritized, a level of effort (LOE) estimate for each back log item based on the team’s standard sprint length (typically 1, 2, or 4 weeks), and the estimated velocity (number of points the team completes on average each sprint) of the team. 

During the release planning session, the team should: 

1. Determine a release cadence: Teams may choose to implement smaller releases after every sprint or release the work from multiple sprints at the same time. 
2. Review the product vision, product backlog, and team velocity: Reviewing product artifacts ensures the backlog prioritization fits the product vision. The team should also review the product backlog to provide the most accurate estimates and identify any missing backlog items. 
3. Confirm date, scope, and project budget: Documenting milestone dates and events, the scope of each release, and the overall budget informs the context of the release plan and highlights gaps in planning. Reviewing the budget can be especially useful if the team plans to employ new tools in development. 

By totaling all the estimates and sorting the work items into sprints based on velocity, the resulting Release Plan will provide a high-level map of work items that will be completed in each sprint and the minimum feature set that will be included in each release using the release cadence. Based on the number of sprints needed to complete the set of work items, the Release Plan will provide an expected completion date. 

• For example: A product backlog has a total estimate of 80 points. The team’s velocity is 10 points per sprint, so completing the backlog will take 8 sprints. If sprints are 2 weeks in length, this will take the team 16 weeks or ~4 months. Prioritized work items can be divided into sprints that contain 10 points each where the highest priority items are planned for Sprint 1. 

Release Planning Best Practices 

By incorporating the best practices below when creating your release plan, you can better position your team to avoid some of the common pitfalls. 

• Include all activities on the backlog: The backlog should be an accurate representation of ALL the work items required in development. This can include research activities, bug tickets, and any activities needed to release the completed work items. It is impossible to capture every activity at the outset of a project, but defining as much as possible (even less defined or nebulous work items) on the backlog will allow the sprint team to generate the best time estimates. 
• Collaborate with the entire sprint team and stakeholders: Release Planning requires collaboration and visibility. Business stakeholders should be involved in the prioritization of backlog items. Creating consensus and awareness of resources needed before a release (e.g., marketing, training, etc.) are all benefits of collaborating with stakeholders in release planning. The sprint team must collaborate on estimating backlog items and velocity, identifying dependencies, and determining sprint operations like sprint length and release cadence. Having input from all parties will help set the team up for the best outcome. 
• Update the plan often: As requirements are better defined, velocity changes, or dependencies are uncovered, the release plan should be inspected and updated after each sprint. Maintaining the most accurate release plan fosters shared understanding between the sprint team and stakeholders. Evaluating the release plan should occur during Sprint Review where the sprint team demos their work and reviews the backlog with stakeholders.  
• Visibility on what is NOT included in a release is just as important as showing what is included: In release planning, it is important to be clear about the features that are not being released. Keeping your plan updated and collaborating with stakeholders will help increase visibility and alignment, but it is important to clearly define what is out of scope for both the sprint team and the business stakeholders. This helps ensure alignment and transparency with stakeholders and level sets expectations for the product.  
• Respect the Definition of Done: Work items being released should always meet the definition of done. This limits technical debt and critical defects. A feature may be planned for release on a specific date, but do not be afraid to ADAPT if it is not done. 

Release Planning can be an important tool when looking multiple sprints into the future. It can also help answer key questions and create visibility around a project. Happy planning!