releavo
Templates · Change request template
Product brief templatePRD templateUX spec templateArchitecture doc templateEpic templateUser story templateReadiness check templateTest plan templateChange request templateRelease notes template
Template 9 of 10

Change request template

A change request is how a change to already-approved scope, behaviour or dates gets decided instead of just happening. It shows what the change touches and what it costs, and leaves the decision with the product owner.

Signed off by:
The product owner
Comes after:
Test plan
Leads to:
Release notes
CR-4 per-account SKUs.md
# CR-<n> · <short title>

**Raised by:** <name> · **Date:** <today> · **Status:** Open

## The change
What's being asked for, in the requester's words, then restated precisely.

## Why

## Impact
| Doc | Section | What would change |
|---|---|---|

**Stories:** affected stories by key, with the change to each and an estimate delta in points.
**New work:** any new stories, with points.
**Dates:** effect on the current sprint and the next milestone.
**Risks:**

## Options
1. **Now:** in the current release; cost in points, what slips.
2. **Next release:** what ships without it, and when it lands.
3. **Don't do it:** what the requester loses.

**Recommendation:** one option and why, in two sentences.

## Decision
_Waiting for <product owner>._

When to raise one

Whenever someone wants something changed that's already approved: scope, a behaviour, a limit, a date. Small changes too. A CR that takes ten minutes to write is cheaper than a sprint built on two versions of the truth.

How to fill it in

  • The change. Quote the requester, then restate it precisely. The two often differ, and the difference is usually the real question.
  • Impact. Walk the doc chain in order (brief, PRD, UX, architecture, epics, stories) and list every section that would change. Don't guess at titles; read each doc.
  • Stories. Each affected story with its change and the estimate delta. Say how confident you are in the numbers.
  • Options. Always at least three, including "don't do it". Each says what it costs and what slips.

After the decision

Only once the product owner has decided: update each affected doc in chain order, changing only the affected sections, update the stories, and set the CR's status to Approved, Deferred or Rejected with the date. Tell the people whose work changes, especially owners of stories already in progress.

Common mistakes

  • Changing the PRD first and writing the CR afterwards.
  • Impact that lists docs but not sections, so the updates miss something.
  • No "don't do it" option.

Example

CR-4 · Match customers' own SKUs

Raised by: Dana · Date: Feb 3 · Status: Approved (Feb 5)

The change

"Two big accounts use their own product codes, can uploads understand them?" Restated: uploads match each account's own SKUs as well as Northwind's.

Impact

DocSectionWhat would change
PRDFunctional requirementsNew FR-5: per-account SKU maps
ArchitectureData modelNew account_skus table

Stories: BO-3 +1 point (suggestions include mapped SKUs). New work: BO-10, import an account's SKU map, 5 points. Dates: fits the March release if BO-6 moves to April.

Options

  1. Now: 6 points; BO-6 (export cart to sheet) slips to April.
  2. Next release: the two accounts keep typing those lines until April.
  3. Don't do it: the two accounts, 18% of bulk volume, don't use uploads.

Recommendation: Now. The two accounts are a fifth of the volume the feature is for, and BO-6 was a nice-to-have.

Decision

Approved by Sam, Feb 5.

Have Releavo write the change request

In Releavo this lives at changes/CR-4 per-account SKUs.md. Releavo drafts it from the docs before it and your team's conversations; every edit is a draft until the product owner approves it, and approved versions are never overwritten.

Start a project, freeHow Releavo works