Skip to main content
Agile & Product Management

Agile release planning: a guide and best practices

A driving principle in Agile development is that we want to move useful software quickly into production by issuing frequent, incremental releases.

Release planning in agile guides this rapid, iterative deployment methodology, providing structure to the team’s efforts while remaining flexible in the face of the inherent unpredictability of software development projects.

What is Agile release planning?

In Agile, we typically define a release as the smallest group of software features that can be effectively bundled together and deployed to the users. A release plan aims to outline the expectations and goals of the next few sprints to deliver this release.

This idea of the smallest group of features, often called the “minimal market features,” is different from what we see in some other development models where releases can be major events that deploy substantial new functionality. A release plan is a high-level plan that might include two to six months of effort and anywhere from three to ten sprints or more.

Agile release planning
Agile release planning diagram

What is the purpose of release planning in agile?

Agile release planning is a critical part of the decision-making process for a team. Release plans help teams decide how much functionality can be delivered and how long it will take to develop that functionality.

They’re also excellent tools for communicating with others in the organization and ensuring clear expectations about what is coming.

Perhaps most important, release plans provide a perspective for the development team that puts the individual sprints in the context of the project’s larger strategic vision while remaining detailed enough to help support day-to-day activities and ensure the project stays on course.

Who is responsible for release planning in Scrum?

Release planning should be an activity that involves the whole development team, bringing in every member’s expertise and building buy-in for the plan.

Release planning is typically led by a product owner, and, in addition to the development team, your scrum master and upper management may also wish to join the session, depending on the structure of your team and individual interest.

The difference between a release plan and a product roadmap

Release plans and product roadmaps are similar project management tools – sometimes to the point of confusion. However, they each have a distinct role in the development process and important differences in the information they track.

Release plans sit below product roadmaps in the project management hierarchy. In Agile, we talk of the planning onion, describing a framework that progresses down a series of layers moving from strategic to tactical ones. The specific terminology might vary a bit among Agile practitioners. The basic framework spans the product vision, product roadmap, release plan, sprint plan, and daily standup.

Agile release plan strategic and tactical steps

Roadmaps show a longer-term perspective, including multiple releases and sometimes even multiple projects. Being strategic tools, they aim to capture the product vision. They communicate product and release goals and present high-level features and product capabilities.

Release plans are shorter-term and decidedly more granular. They’re more tactical than roadmaps focusing on specific work to be done and showing details down to the level of individual backlog items.

Of course, a project relies on both the product roadmap and the release plan.

As time passes and inevitable changes come along, keeping the two perspectives aligned is important. A change in the overall strategy for a product, as reflected in the product roadmap, is almost certain to mean changes in priorities for the features being planned for release.

At the same time, challenges at the release level, such as delays in working through the backlog, will ripple through the planning process and ultimately affect the product roadmap.

When is agile release planning done?

As mentioned earlier, the release plan is beneath the product roadmap and above the sprint plan in terms of planning order. Therefore, release planning should happen when a team is ready to begin working on a new release (this could be after a previous one is complete or when starting on a new product). This would occur, however, after the roadmap has already been planned and confirmed.

Describes how to use ZenHub's Roadmaps to eliminate the disconnect between work in GitHub and your roadmap.

How to create an agile release plan:

The main objective in release planning is to identify the next group of minimal market features and establish the date for that release.

Creating an Agile release plan involves the following steps:

1. Define your release goal

During release planning, You and the team need to articulate the release’s overall goal and how the release is aligned with the larger vision and strategy for the product.

For example, at Zenhub, we used Release Reports to manage the work involved as we prepared to launch Roadmaps version 1. Here’s our report for the project:

release planning in zenhub
Release planning in Zenhub

The goal we defined for this release was to introduce a feature that would drive team alignment for organizations and provide all stakeholders across the company with an up-to-date view of the progress of business-critical software projects.

2. Review and prioritize backlog tasks

Once you’re clear on the goal for the release, the next step is to go through the backlog and rank your team’s work items, prioritizing them according to their support for the release goal.

The result of this step provides the minimal market features for the Agile release. Remember that you’re trying to identify the most important features to support the goal, so you must be prepared to leave less important features for future releases.

3. Estimate the release

To support the planning process, as many backlog items as possible identified in the prior step should have up-to-date story point estimates.

Together with your team, review all the estimates, update them as needed, and develop new estimates for any backlog items that have not yet been estimated.

For Zenhub Release Reports, the report is based on story points in order to provide the most accurate data. We recommend estimating as many issues as possible.

If you haven’t estimated every single issue, that’s no problem. All non-estimated issues will automatically be assigned an average estimation as long as at least one Issue in the report is estimated.

4. Determine the number of sprints

Based on the total number of story points estimated for the release and the team’s velocity, you can calculate the number of sprints needed to complete the work.

Since velocity is a measure of how many story points the team can complete in a sprint, if a release includes 80 story points and the team has a velocity of 20, we know the team will need 4 sprints to work through backlog items identified for the release.

With Zenhub you can easily and automatically calculate your current velocity using the Velocity Charts feature. When you use GitHub Milestones and sprint planning in your workflow, Zenhub will calculate your average velocity based on your previous 7 sprints and current open 3 sprints.

See our support article Track team Velocity sprint-over-sprint to learn more about this core Zenhub capability and how you can incorporate it into your release planning process.

velocity report for release planning in Zenhub
Velocity tracking in Zenhub

5. Create a release sprint

A release sprint is dedicated solely to releasing new deliverables. No development is done at this point, but common tasks within your backlog during a release sprint include performance testing, user documentation completion, error fixing, and more.

Not all projects need this step, but if your workflow has specific tasks associated with moving software into production, you may create an additional sprint for completing those tasks.

6. Identify a target date for the release

The target date is a function of how many sprints are scheduled for the release.

In Zenhub, you set your desired end date when creating the release. As you progress through the release, the report calculates a predicted end date based on your team’s actual velocity (how quickly issues are then completed for the release).

7. Update the release plan continuously

Revisit the release plan regularly, checking to see how the team is performing against the plan and looking for any changes that might impact what features will be delivered or the delivery date. If there are changes, the plan will need to be updated, and you may need to communicate with business owners and others.

Zenhub continuously calculates your predicted end date based on the team’s actual velocity. If you’re seeing a significant gap between your actual and desired velocity, it should prompt a conversation with the team to understand what’s happening. In case the predicted end date is later than the desired end date, you may need to either cut the scope or change the release date.

Agile release planning through Zenhub

Zenhub Release Reports brings a dynamic, real-time perspective to your process. With Zenhub you plan releases quickly and easily using existing GitHub data.

Your release data is presented in an intuitive interface, letting you see how the team is performing against the plan and whether or not you’re on track to finish the release by the desired end date.

Release Reports lets you go further than GitHub Milestones to manage work that spans multiple sprints. You can pull in GitHub Issues across any repositories in your organization and build a release around those issues, supporting planning for longer-term goals across multiple teams and objectives.

To be effective, your release planning process must be sufficiently nimble to adapt to project changes and new information. All projects will experience some flux over their lifecycle. Early estimates can be too optimistic, unanticipated challenges can arise, and changing priorities can force you to reprioritize tasks.

Zenhub supports responding to these changes and helps you assess ongoing project performance so you can fine-tune your plans.

FAQs

How often should Agile release planning meetings occur?

Agile release planning meetings frequency can vary based on the project’s needs, team size, and the duration of sprints. Typically, they occur at the start of a project and then at regular intervals, aligned with sprint reviews or critical project milestones.

What is the difference between release planning and sprint planning?

Release planning focuses on defining a roadmap for the product over a longer time horizon, outlining what will be delivered in each release to achieve strategic goals. It’s about the big picture and long-term objectives. Sprint planning, on the other hand, is more immediate and detailed, determining the work and tasks to be completed in the upcoming sprint, typically lasting 2-4 weeks. It involves breaking down items from the backlog into actionable tasks for the sprint.

How do teams measure success in Agile release planning?

Success in Agile release planning can be measured through a variety of metrics, including the completion rate of planned features, adherence to the release schedule, and stakeholder satisfaction with the deliverables. Much of this can be found in Zenhub’s release reports.

Closing tips for an effective agile release plan

For your next Agile release plan, stick to a couple more best practices that are bound to minimize most risks during the entire release sprint:

  • Monitor progress throughout all sprints by keeping your initial SMART (Specific, Measurable, Achievable, Relevant, and Timely) goals in mind and adapting as you go.
  • Never release work that’s undone. This refers to tasks that are still in production and could incur additional technical debt – the cost of extra work that needs to be done just because you chose the easiest strategy that didn’t provide the right results.
  • Clearly define the roles for release planning. A product owner, for instance, can be in charge of releasing goals, writing epics and user stories, and initiating the acceptance criteria. On the other hand, the Scrum master will organize and moderate all meetings, run regular reporting, or simply consult with other team members for best Scrum practices.
  • Ditch your daily stand-up meetings by replacing them with a Slack channel or work board. Consider doing this for all sprints to reduce time spent on administrative work.

Zenhub release reports make it easy to use your existing GitHub data to create dynamic, comprehensive release plans that help your team succeed. To learn more, visit the Help Center to learn more about how to plan long-term projects using release reports.

 

 

Goes over how to take sprint planning from hours to minutes with ZenHub Sprints.

Share this article

New
Work smarter, not harder. With Zenhub AI

Simplified agile processes. Faster task management. All powered by AI.

Get Early Access

Hone your skills with a bi-weekly email course. Subscribe to Zenhub’s newsletter.

Return to top