Release plan template

A release plan is a short plan for getting one release out: what is in it, how you know it is ready, who needs to hear and how to undo it. A release plan template gives you the sections. It is not a roadmap, which sets order over months (see What is a product roadmap?). It is the plan for the next thing you put in front of customers.

TL;DR

• List what is in the release and the evidence behind each item.
• Check every Done When line before you ship, and say which are not checked.
• Name who to tell and have the note ready.
• Write the rollback before you need it: who decides, how, and how you will know.

When to use it: a release that touches billing, data or many customers, or a batch of changes your agents finished at once. When not: a one-line fix that is easy to undo. Ship it and write the note.

A release plan template

Keep it to one page. Fill it in before the release goes out, not after.

# Release <number or name>: <headline in a customer's words>

Date: <planned date, or "when ready">
Decides to ship: <name>

## In it
1. <What becomes true> (priority: <link>)
2. <What becomes true> (priority: <link>)

## Evidence
- Item 1: <requests in their words, accounts, revenue, or "a bug, marked P_">
- Item 2: <...>

## Done When, checked
- Item 1: <line> | Checked: <test, staging link or screenshot>
- Item 1: <line> | NOT checked yet: <why, and when you will check>

## Who to tell, and the note
- <people who asked, by name>: "<2 or 3 sentences, what changed for them>"
- <your team>: "<one line>"
- <anyone who answers questions about it>: "<one line>"

## Rollback
- How to undo: <flag, revert, previous version>
- Known-good version: <release or commit>
- Triggers: <what would make you do it>
- Decides: <name> | Does it: <name>

## After
- Check on <date>: <the one thing to look at in real use>
- Result: <what you saw>

What goes in each part?

What is in it. A line per item, in words a customer would use: "Pause a subscription instead of canceling". Link each to its priority or spec. If something is half done, it is not in.

Evidence. Why each item is here: the requests in the customer's words, the accounts and the revenue, or "a bug an agent found, marked broken". This is how you answer "why this and not that?" a month later.

Done When, checked. Each line from the spec, with how it was checked: a test, a staging link, a screenshot. A line you could not check stays unchecked, and you write that. "Merged" is not the same as "works".

Who to tell. The people who asked, your own team, anyone who answers questions about it. Name them, not "customers". Start with the people who asked.

The note. Two or three sentences for each group, ready before you ship. What changed for them, in their words. It saves the scramble after.

Rollback. What you will do if it goes wrong: how to turn it off or go back, who decides, who does it, and what would make you do it ("invoices fail to open for more than a few accounts"). Write the known-good version, so nobody hunts for it at the worst moment.

After. One check a day later: did it do what the Done When lines said, in real use? Note it. That is the next release's evidence.

An example, filled in

This is an example, made up to show the level of detail.

Release 14: pause a subscription, plus two fixes

In it

1. Pause a subscription instead of canceling (3 accounts asked).
2. Invoices open on the first click (a bug an agent found).
3. Reminder email says the right return date (a bug a customer reported).

Evidence. Item 1: Northbeam Studio ($49 a month), Fieldnote ($99), Tallow & Co ($49), in their words in the spec. Item 2: marked broken (P1), seen on 4 accounts. Item 3: one account, Dana at Northbeam.

Done When

• Item 1: pausing for 2 months creates no invoice. Checked: test run, staging link.
• Item 1: a paused account shows the return date. Checked: screenshot.
• Item 1: an annual plan shows no Pause button. Not checked yet: no annual account on staging. Will check on production after release.
• Item 2: invoice opens on first click. Checked: staging link.

Tell

• Northbeam, Fieldnote, Tallow & Co: "You can now pause instead of canceling. Billing stops, your data stays."
• Dana: "The reminder email now shows the date you chose."
• Our team: a line in the team channel.

Rollback. Turn off the Pause button with the flag. Cat decides, Sam does it. Triggers: any invoice created for a paused account. Known-good: release 13.

After. Next day: check paused accounts have no invoices. Note it here.

When is a release plan overkill?

When the release is one small change you can undo in a minute. Then the plan is a sentence in the note. It also tips into overkill if the plan takes longer than the work. Cut parts that nobody reads. Keep the rollback and the checked Done When lines: they are what you will want when something is wrong.

Does it work when agents did the building?

Better than most. Agents finish work fast, in batches, and a batch is where it gets hard to say what is in the release and what was checked. Make each agent record its check against each Done When line, and the release plan is mostly reading those. You still decide what goes out. Nothing in this plan should ship because an agent said it was done. See definition of done for AI agents.

How does Annsa help?

Annsa is the source of direction for your agents, and it keeps the parts of this plan with each priority.

• Evidence stays attached. Each priority holds the requests in the customer's words, the accounts and the revenue.
• Done When lines are recorded. Claude Code, Cursor, Codex and Grok connect over MCP, read the spec and record evidence against each Done When line.
• Shipped work is cut into numbered releases, and the changelog shows them.
• Telling people. Share Back drafts a note to each person who asked. You send it.

Annsa does not run your rollback. That stays with your team and your deploy tools. For the note itself, see how to write release notes and closing the feedback loop.

Sources: Release management, Wikipedia.