Loading...
Arrow left
Blog Homepage

Agile Release Planning in Software Development - Step-by-Step Guide

Agile Release Planning in Software Development - Step-by-Step Guide

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

The Agile release planning process 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.

This idea of the smallest group, sometimes called the minimal market features, is different than what we see in some other development models where releases can be major events deploying substantial new functionality at one time.

A typical Agile release might include two to six months of effort and anywhere from three to ten sprints or more.

What Are the Objectives of Release Planning?

Release plans help teams make decisions about 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 making sure that there are 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 be helpful in supporting day-to-day activities and making sure the project stays on course.

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 the 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.

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

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 the inevitable changes come along, it's important to keep the two perspectives aligned. 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.

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.

You need a framework that will not only support responding to these changes on the fly but also help you assess ongoing project performance so you can fine-tune your plans.

Let’s get to it!

Steps for a Successful 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.

Release planning should be an activity that involves the full development team, bringing in members’ expertise, and building buy-in for the plan.

Creating an Agile release plan involves the following steps:

1. Define your Release Goal

During release planning, You and the team need to be able to articulate the overall goal for the release 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:

agile release report created with 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 into 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 need to 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

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 velocity and your desired velocity, it should prompt a conversation with the team to understand what’s going on. In case the predicted end date is later than the desired end date you may need to either cut scope or else change the date of the release.

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 makes it easy to use your existing GitHub data to create dynamic, comprehensive release plans that help guide your team to success. To learn more, visit the Help Center to find out more about how you can plan long-term projects using release reports.

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

Product Management
Newsletter Icon