Release Schedule Template: 12-Week Sprint Example

A sprint release plan template you can copy

Here is the schedule above as a table, filled in at the start of the quarter. Copy it into a sheet, a wiki page or a database, then change the versions, weeks and names.

• v2.1 (minor, closes Sprint 2): code freeze Monday of Week 4, QA window Monday to Wednesday of Week 4, go/no-go Wednesday of Week 4 (product owner), planned release Thursday of Week 4, actual release not yet, rollback owner tech lead, comms to support and sales the day before and to customers on release day, status planned.
• v2.2 (minor, closes Sprint 4): code freeze Monday of Week 8, QA window Monday to Wednesday of Week 8, go/no-go Wednesday of Week 8 (product owner), planned release Thursday of Week 8, actual release not yet, rollback owner tech lead, comms to support and sales the day before and to customers on release day, status planned.
• v3.0 (major, closes Sprint 6): feature complete at the end of Week 10, rollback rehearsal in Week 11, code freeze Monday of Week 12, QA window Monday to Wednesday of Week 12, go/no-go Wednesday of Week 12 (product owner), planned release Thursday of Week 12, actual release not yet, rollback owner tech lead, support briefing and help articles in Week 11 and customers told on release day, status planned.

What each column means

Keeping the planned date next to the actual date is what makes the schedule useful later. After two quarters, the gap between the two columns shows you how much buffer the team really needs.

• Version and Type: the version number, and whether it is minor, major or a hotfix.
• Closing sprint: the sprint whose work this release ships.
• Code freeze: the date and time after which only fixes are merged.
• QA window: start and end of regression testing.
• Go/no-go: the meeting date and the person who decides.
• Release date (planned and actual): fill the actual date on release day.
• Rollback owner: who runs the rollback, and where the steps are written.
• Comms: who gets told, and when.
• Status: planned, in freeze, in QA, released or rolled back.

Release schedule, release plan and roadmap: what each one answers

These three documents get mixed up, yet each answers a different question. A product roadmap explains why and in which order: the outcomes the team is chasing over the coming quarters. A release plan explains what: the scope, risks and stakeholders of one version. A release schedule explains when: the dates that every release moves through, row by row.

A single release plan template covers one version in depth: objectives, scope, owners, risks and how success will be measured. A release schedule sits above several of those plans and keeps their dates in line. Most agile teams need both: one short plan per major release, and one schedule that everyone checks on a normal Tuesday.

Choosing your agile release cadence

An agile release plan template only works if the cadence fits how the team ships. There are three common patterns.

Base the cadence on the slowest step in your process, not the fastest. If manual QA takes three days, a weekly release will skip testing sooner or later. Many teams combine cadences, as in the example above: minor releases on a steady rhythm, and a quarterly major release for changes that need training or customer notice.

• Every sprint: suits web products with automated tests and feature flags. It keeps releases small, but needs a fast, reliable QA process.
• Every two sprints or monthly: suits teams that run manual regression tests or ship to app stores. It leaves room for one hardening week per release.
• Quarterly: suits enterprise software, regulated products or customers who need notice before changes. It needs a strict feature-complete date and a full hardening sprint.

Buffers, dependencies, holidays and capacity

Most release dates slip for reasons you could see weeks in advance. Before you publish the schedule, check four things.

Put these checks in a small notes column next to each row. When a date moves, the reason is already written down.

• Holidays and leave: a freeze week with half the QA team away is not a real freeze week. Move the date or the scope.
• Dependencies: list every other team, vendor or approval each release relies on, with the date you need it.
• Capacity: plan sprints below the team's full availability, so bug fixes and support work do not eat into the release.
• Buffer: put your buffer before the go/no-go meeting, not after the release date. A hidden buffer gets spent on scope.

Go/no-go criteria, roles and rollback

A go/no-go meeting is only quick if the criteria are agreed in advance. Write them once, at the top of the schedule, and reuse them for every release.

The roles split simply. The release owner is accountable for the date. The engineering lead is responsible for the build and the rollback. QA confirms the test results, and the product owner makes the go/no-go call. Support and sales are kept informed. Write these names into the template so nobody has to ask during freeze week.

• No open critical or high-severity bugs in the release scope.
• Regression tests passed in staging.
• Rollback steps written and, for major releases, rehearsed.
• Release notes and the support briefing are ready.
• The on-call engineer for launch day is named.

Release plan template in Confluence, Google Sheets, Excel and Notion

The fields stay the same in every tool.

Pick the tool your stakeholders already open every week. A schedule that nobody looks at drifts quickly, however well it is built.

• Confluence: create one page for the quarter with the table above. Add a child page per major release for its goals, people and risks, and link each row to the matching Jira version.
• Google Sheets or Excel: paste the table, keep one row per release, and add conditional formatting on the status column. Add a second tab for go/no-go criteria and roles.
• Notion: a database with one entry per release, a timeline view grouped by sprint, and a status property. Each entry's page holds its rollback steps and comms checklist.

Presenting the schedule to leadership

Leadership does not need every freeze and QA date. Show one visual timeline for the quarter, with the three release dates as milestones and the major release clearly marked. Under each milestone, add one line on what customers will notice.

Then show what could move the dates: the dependencies and the buffer. End with the decision you need, for example approval of the v3.0 scope freeze. Keep the detailed table as a backup slide or a link for anyone who asks.