Release Plan
A release plan is a short- to medium-term plan that describes what a team intends to deliver in an upcoming release or series of releases, roughly when, and with what scope. It turns part of the product roadmap into concrete epics and user stories sequenced across sprints, so the team and its stakeholders can coordinate building, testing and launch.
How a Release Plan Works
A release plan typically includes:
- A release goal: the single most important thing the release should achieve.
- A target date or window, set either as a fixed date with flexible scope, or a fixed scope with a forecast date.
- Scope: the prioritized epics and stories expected to be included, with the most important first so lower items can be cut if needed.
- A capacity forecast, often based on the team's historical velocity, showing how many sprints the scope is likely to need.
- Dependencies and risks that could affect the date, such as work from other teams.
- Launch activities like documentation, support training, marketing and customer communication.
The plan is updated as work progresses. Each sprint adds real data about progress, and the team adjusts scope or the forecast date accordingly. Tools such as a release burndown chart make the remaining work visible.
Why a Release Plan Matters
A roadmap explains direction and priorities; it rarely says which stories ship in which release. The release plan fills that gap. It gives engineering a realistic delivery target and gives sales, support and marketing enough notice to prepare.
It also exposes over-commitment early. When the forecast clearly cannot fit the scope into the window, the team can negotiate scope or dates weeks in advance instead of discovering the problem at the end.
In teams that deploy continuously, the release plan often describes when features are turned on for customers rather than when code is deployed, since the two can be separated with feature flags.
Release Plan Example
A team plans version 2.0 of its invoicing app, with a goal of "let small businesses get paid online." The window is six two-week sprints. Scope, in priority order: card payments on invoices, automatic payment reminders, a payment status dashboard, and partial payments. Based on recent velocity, the forecast fits the first three items comfortably and the fourth only if everything goes well, so partial payments are marked as a stretch. A dependency on the payment provider's sandbox access is flagged as the main risk, and support training is scheduled for the final sprint.
Release Plan vs. Product Roadmap
| Product roadmap | Release plan | |
|---|---|---|
| Purpose | Strategic direction and priorities | Tactical delivery of a release |
| Typical horizon | Often around a year or longer | A few sprints to a few months |
| Content | Goals, themes, outcomes, initiatives | Epics, user stories, dates, capacity |
| Main audience | Leadership, teams, sometimes customers | Delivery team and launch partners |
Product coach Roman Pichler describes the roadmap as the longer-term strategic plan and the release plan as the tactical plan for a single major release, noting that big changes to a release plan are likely to affect the product roadmap too. Getting the release into users' hands safely is a separate discipline, release management.