---
name: connect-quality-strategy
description: Write the quality strategy up as one document from the records, straight after the release priorities - an opening, then a section for each priority ending in its open questions and their next actions - then check it against its sources and give it to the user. Use after the priorities, again when the strategy owner wants the whole document reread and checked, or when a step is waiting on the user and they want what exists written up.
---

# Write the strategy up

Quality is value to someone who matters. The approach to quality strategy in this pack derives from
the Context Driven Testing school: start by describing who matters, describe what matters to them,
then prioritise the work to achieve it. The approach is not dogmatic - coverage, checklists,
standards and established practice can all be part of the strategy, sometimes they are the exact
right thing for some stakeholder or some quality dimension. The key thing is the overall approach -
based on context, and understanding what this project needs to achieve.

This step writes the strategy up straight after the release priorities, so that what has been
decided can be taken away and worked from. Where the records answer something, write the answer; everything else is
written as a question with its next action, because the write-up does not wait for the questions to
be answered.

It is for a reader who was not in the conversation: the strategy owner coming back to it, the
people working on the project, and agents working on it, often the owner's own agent reading it
for them.

**Done when** the strategy is one document a reader could act on: an opening they can make a
decision from, and a section for each priority not rated None that ends with its open questions,
each with its next action or saying that no way is chosen yet. It holds no fact the records do not
and no decision the owner has not made, and shows who said or proposed each thing. Nothing in the
interview, the project context and the profiles was lost on the way. You have checked it against its
sources and a reader who did not write it has reviewed it, or the owner knows that nobody else has;
the step is recorded, and the owner knows where the document is.

How to talk with them, and what to do when they do not know, is in [working on a
strategy](../../references/strategy-workspace.md): read it before your first message.

## 1. Read the records

Every fact and decision in the strategy comes from the records, because writing it up adds no
evidence and makes none of the owner's decisions; a suggestion of yours, marked as yours, is
neither. Open [before writing](references/before-writing.md) and do what it says.

## 2. A section for each priority

Write the sections before the opening, because the bottom line and the first next actions are taken
from them. First read [what a good strategy is](../../references/strategy-template.md#what-a-good-strategy-is),
because every part is judged by it. Then write a section for each priority not rated None, however
little is known about it, as [the template](../../references/strategy-template.md#the-sections)
describes.

- **The four parts come in the template's order,** because each rests on the one before. A part
  with nothing known says so in a line.
- **Before writing a section, gather what every record holds that bears on each of its parts,**
  because the records are kept by the step that heard each thing and the strategy by part, so the
  joining is yours and not the reader's. For what good looks like: what anyone has said about how
  good it must be, limits and what would be more than needed, the stakeholders' levels and
  obligations. For how we will know: what the owner has said would count as evidence or how they
  would find out, what the pre-read says the tests cover, and how work is checked. For where it
  stands: the owner's own observations, the pre-read's findings and the interview. For what to do:
  each open question's recorded way.
- **What good looks like** says what it would cost, and whom, if the priority fell short, because
  that is what a reader weighs. **Where it stands** says how far short of the bar the evidence puts
  it, or why it cannot be judged against the bar yet, and what that puts at risk for whom. It names
  any fault already known and says whether it can be fixed without waiting for anyone.
- **Claim no more than the records do.** Where an earlier step recorded an interpretation, such as
  an agent's reading of what was seen, write it as that interpretation, with its date, and add "not
  seen by the owner" where they never saw it, because the write-up is where an interpretation is most
  easily copied out as a fact.
- **Each question goes in one section, once,** because a question written in two places is the one
  that gets lost. Put every question the records still hold open in the section it bears on, as an
  item a reader can find: the question and its next action, with whose it is, in a sentence or two,
  with the reasoning in the prose above. Questions that one piece of work would answer together can
  be one item that names them.
- **Each item ends with the next move and whose it is,** the very next concrete thing to do, small
  enough to do without more planning, with no date that nobody gave; or it says that no way has been
  chosen yet. A move you suggest is marked as your suggestion. A sitting or a brainstorm is a move
  when it says what it is for, what it should produce and who runs it; "owner and agent work out
  how" says none of that.
- **Where little is known, the section is short** and still ends with its questions. It ends with
  none only when the priority is known to be where it needs to be, and the section says how that is
  known.

## 3. The opening and the parts around the sections

Write the opening from the sections. Then write, or bring up to date with what the records now
hold, the other parts [the template](../../references/strategy-template.md) describes: the project,
the release, who matters and what matters to them, what this release will not do, the priorities,
and the end, with the dates and the pack version. Take the project, the release and who matters
from the project context and the profiles, which are complete by now, and write them for a reader
who will not open those records.

- **The opening** starts with a sentence or two that tell someone without the background whether
  the document is for them, then gives the bottom line. It is read later, so it gives a date or a
  condition, never a word like "tonight".
- **The bottom line** is one short paragraph on the whole release, for a reader deciding today.
  Think it through first: is the release ready, or how far off; what is known to be wrong, and can
  it be fixed without waiting; what do the unknowns add up to; and what one thing would most change
  the picture. Lead with what bears most on whether the release can go, because a true picture with
  gaps serves a reader better than a reassuring one that comes from not having looked. Link to the
  sections for what is wrong or unknown rather than listing it. Where stakeholders want different
  things, or someone still has to make the release call, show that rather than smoothing it over.
- **The rules the owner has given** are their limits on how the work is done, whether or not they
  ranked them, because every next action has to fit within them.
- **The priorities part** holds what the priorities step decided, Once the sections say enough, add
  a few lines there on the pattern across them, such as one known blocker set against uncertainty
  that many priorities share, unknowns that one conversation could settle, or which priorities
  depend on others. Do not repeat the sections there.

## 4. Check it against its sources

Open [the review](references/review.md) and do what it says.

## 5. Hand back

Open [handing back](references/hand-back.md) and do what it says.