# How to plan a software release, step by step

> Plan a software release in seven steps: fix the date, freeze the scope, split the work by team, track blockers and decide go or no-go. With a checklist.

A release is a promise: this, by that date. Planning one means fixing the date, deciding what is in, splitting the work by team and watching what is blocked until the day.

Web page: https://kansohq.app/guides/how-to-plan-a-software-release

Updated: 5 October 2026

## What release planning is

Release planning is deciding what will ship, when, and what has to happen first. It turns “we should launch soon” into a date, a list of work with owners and a way to see, any morning, whether the date is still safe.

## The seven steps

1. **Fix the date, or the scope, but not both.** If the date is fixed, scope flexes. If the scope is fixed, the date does. Say which one you are choosing.
2. **Decide what is in.** List every candidate item and rank it. The [MoSCoW method](https://kansohq.app/guides/moscow-prioritization.md) works well: Must, Should, Could, and what you will not do.
3. **Freeze the scope.** After a set point, a new Must requires an old one to leave.
4. **Split the work by team.** Product, engineering, QA, design, go-to-market and support each get their own list under the one date.
5. **Give every line an owner, a due date and a status.** Todo, in progress, blocked or done. A line with no owner is not planned.
6. **Track what is blocked.** Review blockers daily in the last two weeks. A blocked line that is not discussed becomes a late release.
7. **Decide go or no-go in advance.** Name who decides, what they will look at and when. Use the [launch checklist](https://kansohq.app/guides/software-launch-checklist.md).

## What a release plan looks like

**Release 3.4, ship date 14 November**

> **Product:** finish the onboarding copy (owner: product lead, due 28 October, in progress)
> **Engineering:** migrate the notification queue (owner: engineering lead, due 4 November, blocked on staging access)
> **QA:** run the full test plan on the release build (owner: QA lead, due 7 November, todo)
> **Go-to-market:** write the release notes and tell support (owner: support lead, due 11 November, todo)

## Signals that the date is at risk

- More than one blocked line for more than two days.
- Lines due this week that nobody has started.
- New Musts added after the scope was frozen.
- The same item moving its due date more than once.

When you see them, act early: move a Should out, add help to the blocked line, or move the date and say so. Moving a date in week one is a conversation. Moving it on the last day is a failure.

## After the release

Look at the numbers after a day and a week, thank the people who carried the hard parts and hold a [retrospective](https://kansohq.app/guides/how-to-run-a-retrospective.md). The plan for the next release starts with what you learned.

## Ways to release

How you release changes how you plan. The main patterns:

| Pattern | How it works | Good for | Watch for |
| --- | --- | --- | --- |
| All at once | Everyone gets the release on the same day | Small changes and small user bases | A problem hits everyone |
| Phased | A small share of users first, then more | Changes with risk you cannot fully test | Two versions live at once |
| Behind a feature flag | The code ships off, then is switched on | Separating shipping from launching | Flags that are never removed |
| Scheduled train | A release goes out on a fixed day, with whatever is ready | Larger teams with many changes | Pressure to squeeze work into the train |

## Who does what

- **Release owner:** owns the date, the plan and the go or no-go. One name.
- **Engineering lead:** says what is built, what is risky and what the rollback is.
- **QA lead:** says what has been tested, and what has not.
- **Go-to-market and support:** tell customers, and know what to say when they ask.

On a small team, one person may hold several of these roles. The point is that each question has a name beside it.

## The first week and the last week

The two ends of a release plan feel different. In the first week, the work is deciding: what is in, who owns it, what the date is. In the last week, the work is watching: what is blocked, what is untested, what has changed since the scope was frozen. Plan time for both, and keep the last week as quiet as you can. New scope arriving in the last week is the most common cause of late releases.

## Release planning in Kanso

A [Kanso release page](https://kansohq.app/product/releases.md) gathers the work behind one date into sections, with an owner, a due date and a status on every line. One click narrows it to what is blocked or overdue, and each line links to the real task on your boards, so nothing is written twice. Start from the [launch checklist template](https://kansohq.app/templates/launch-checklist.md) and give each team its own section.

## Questions

### What is release planning?

Release planning is deciding what will ship, by when and what must happen first, then tracking the work and the risks until the release is out.

### Who owns a release?

One named person, usually a product or engineering manager, owns the date and the go or no-go decision. Each line of work has its own owner.

### How far ahead should a release be planned?

Plan the scope as soon as the date is set, and review it weekly. In the last two weeks, review blockers daily.

### What should a release plan include?

The date, the scope ranked by importance, the work split by team, an owner, due date and status for each line, the blockers and the go or no-go criteria.

## Keep reading

- [A software launch checklist, step by step](https://kansohq.app/guides/software-launch-checklist.md): A software launch checklist for product, quality and go-to-market, plus launch day and what to do after. Copy it, give every line an owner and ship.
- [The MoSCoW method: Must, Should, Could explained](https://kansohq.app/guides/moscow-prioritization.md): The MoSCoW method sorts work into Must, Should, Could and Won’t. Learn what each means, how much to put in Must and how software teams use it.
- [How to write release notes people read](https://kansohq.app/guides/how-to-write-release-notes.md): Good release notes say what changed and why it matters, in plain words. Learn the structure, a before-and-after example and what to leave out.
- [Software launch checklist template to copy | Kanso](https://kansohq.app/templates/launch-checklist.md): A software launch checklist template covering product, quality and go-to-market, launch day and after launch. Copy it, or start it in Kanso.
- [Release notes template: what changed and why | Kanso](https://kansohq.app/templates/release-notes.md): A release notes template with a summary, what is new, improved and fixed, known issues and upgrade notes. Copy it, or start it in Kanso.
- [Test plan template for software releases | Kanso](https://kansohq.app/templates/test-plan.md): A test plan template with scope, risks, test cases, environments, exit criteria and sign-off. Copy it, or start it as a page in Kanso.

## Parts of Kanso used

- [Kanso Releases](https://kansohq.app/product/releases.md): A release page gathers the work behind one date into sections, with an owner, a due date and a status on every line.
- [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done.

[Kanso home, with plans and prices](https://kansohq.app/index.md)