A release plan needs five fields: name, purpose, what's in, what's out and a rough target. Anyone on the team should be able to read it in 30 seconds. Copy this:
RELEASE: [version] - [what it's about]
PURPOSE
[One or two sentences on what this release is trying to achieve.]
IN SCOPE
- [Task or small group of tasks]
OUT OF SCOPE (not in this release)
- [Thing you've decided to leave out, and when it might come back]
TARGET
Shippable by [rough date], no hard date.
Will be shipped when the IN SCOPE list is done.
A real example
Here's roughly what v1.16 of Frostbyte looks like written out this way, using the release's description and tasks.
RELEASE: v1.16 - Quick Edit and Chat Connections
PURPOSE
Quick edit on every screen, task suggestions and polish while
creating, and Claude chat and ChatGPT sign-in connections.
IN SCOPE
- Quick edit: area, release, description, instant saves, mobile
- Suggest type, area and release for new tasks
- Polish tasks while creating them
- Sign in with OAuth from Claude and ChatGPT apps
- Fix GitHub integration not working with pull requests
OUT OF SCOPE (not in this release)
- Personalised What's Next recommendations (v1.17)
- User Signals capture and review rework (v1.17)
TARGET
No hard date. Shipped 26 October 2026.
Both out-of-scope items went into the next release. Neither competed with quick edit for attention while it was being built.
How to fill in each field
| Field | Good | Bad |
|---|---|---|
| Name | v1.16 - Quick Edit and Chat Connections | Project Falcon |
| Purpose | Make the public Feedback Portal feel mature for new visitors | Improve the product |
| In scope | Five words per item. If it needs more, it's two items | A paragraph per task |
| Out of scope | Personalised What's Next (v1.17) | Left blank |
| Target | Shippable by mid-October, no hard date | 14 October, unless you have a real external commitment |
Out of scope matters most. It gives you an answer ready for mid-build requests: not this one, possibly the next. How to prevent feature creep covers why. A soft target is also the honest one, as a roadmap without overpromising explains.
What's left out on purpose
- Estimates per task. You only need them to check the scope isn't insane.
- Owners per task. On a small team, people pick up the next thing when they finish.
- Success metrics. Done means shipped with the in-scope work finished. Tracking outcomes is a different doc.
- Sign-off. The team is the stakeholder.
Where it lives
A README, a Notion page or a pinned Slack message all work. What matters is writing it before each release.
In a planning tool, the template maps onto the release itself. In Frostbyte, the purpose and out-of-scope list go in the release description, the in-scope items become tasks and the target goes on the release.
If you're working from a flat backlog at the moment, start with releases vs backlogs.
