Handover brief
A handover brief is a one-page document that gives a delivery team everything they need to start work, without a meeting. It is a Pro feature, and it lives in the Handover readiness section of an item.
What it does
Roadmap Flow decides what to build. Your delivery tool tracks how it gets built. The gap between them is usually a conversation that happens three times and still leaves something out.
The brief closes that gap. It collects the item's problem statement, who it is for, the desired outcome, what is explicitly in and out of scope, decisions you have already taken, the success measure and who to ask — and produces a Markdown page you can copy straight into a work item or save and send.
It carries the words that caused the work
If the item came out of triage, the brief's evidence section is already filled in: the signals that were promoted or merged into it, quoted as they were captured, with the date and where they came from.
That is the one part of a brief nobody can reconstruct later. A work item records what was decided; nothing records the customer sentence that started it, and by the time a delivery lead asks "who actually wanted this?" the answer is usually somebody's memory. Here it travels with the work.
It is quoted, never paraphrased — a paraphrase is what the rest of the brief already is. An item that never came from a signal gets an empty table to fill in by hand, which is what the brief always did.
The rule it is built around
> Hand over when the delivery team can start without asking a business question.
If they have to ask who is this for, what does success look like, or is X in scope — it is not ready, and handing it over just moves the uncertainty somewhere it will sit for weeks.
If they have to ask how do we build this, how long, or what architecture — it is ready. Those are their questions, not yours.
What it deliberately does not decide
The brief ends by saying so out loud. Work item type, how the work is sliced, sequencing, estimates and technical approach all belong to the delivery lead.
This is what makes the brief a handshake rather than an instruction, and it is why a delivery lead is willing to receive one. The Roadmap level at the top of the brief describes where the item sits on your roadmap — it is not a request for a work item of that name.
Getting an item ready
Set an item's status to Tech Readiness and the Check tab starts asking for what the brief needs: an owner team, a description, the desired outcome, what is out of scope, a success measure, a target period, and no open decision.
Who the delivery team talks to.
What the problem actually is.
What "done" means.
The question that comes back mid-build.
How anyone will know it worked.
When it is wanted by.
Nothing still waiting on you.
The three fields specific to handover live in the item's Handover readiness section, which opens on its own once an item reaches Tech Readiness.
Roadmap Flow will not produce a clean brief while something is missing. It lists what is absent and lets you export anyway if you mean to — a brief full of gaps looks finished to the person receiving it, which is worse than no brief.
When to use it
- Handing an item to a delivery team for the first time.
- Reviving something that was parked, where the original context has faded.
- Anywhere the person who will build it was not in the room when you decided.
When not to use it
- For an item still in Discovery. The brief will tell you what is missing, but the honest answer is that it is not ready to hand over yet.
- As a specification. It describes one business outcome; it does not describe an implementation.
Copy or save
Copy brief puts it on the clipboard, for pasting straight into a work item while you are on a call. Save as file writes it to your exports folder when you would rather send it.