Arrow left
Blog Homepage

Agile Release Planning in Software Development

Agile Release Planning in Software Development

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.

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.

Release plans help teams make decisions about how much functionality can be delivered and how long it will take to develop that functionality. They are 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.

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 in place 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.

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.

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 – but 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 which progresses down a series of layers moving from the strategic to the tactical. The specific terminology might vary a bit among Agile practitioners, but the basic framework spans the product vision, product roadmap, release plan, sprint plan, and the daily standup.

Agile onion

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 are 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 is 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.

Steps for a 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 a release plan involves the following steps:

1. Define your Release Goal

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. (A screenshot of our report for the project is below.) 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.

release report

2. Review and Rank the Backlog

Once you are clear on the goal for the release, the next step is to go through the backlog and rank work items, prioritizing them according to their support for the release goal. The result of this step will be the minimal market features for the release. Remember here that you are 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](https://www.zenhub.com/blog/how-to-estimate-software-development-projects-with-story-points/). You and the team should review all the estimates, update the estimates as needed, and develop estimates for any backlog items that have not yet been estimated.

For ZenHub Release Reports, in order to provide the most accurate data, the report is based on story points, so we do recommend estimating as many issues as possible. However, 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](https://www.zenhub.com/blog/how-to-measure-team-velocity-and-meet-deadlines/), 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.

velocity report

5. Create a Release Sprint

Not all projects need this step, but if your workflow has specific tasks associated with moving software into production, you may wish to 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

You should revisit the release plan regularly, checking to see how the team is performing against 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. If 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.

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 and read our article Plan Long-Term Projects with Release Reports.

Product Management
Newsletter Icon