session · build & review

Three-confirmation review

45 minutes per release candidate. PO, QA, Designer each confirm one dimension. Three angles, three signatures. Nothing merges to main until all three approve. The session that makes the chain's "trio" real.

When

Per release candidate — when the developer signals the story is build-complete and asks for review.
Before the release gate — the three confirmations are gate inputs.

Who

PO — confirms the brief's prediction is still served by the implementation.
QA — confirms scenarios pass, exploratory found nothing blocking, accessibility scan green.
Designer — confirms the surface matches the wireframe and the design system, content design holds.

Time-box

45 minutes. Held in one session for efficiency; can be split into three async confirmations if scheduling forces it — but the synchronous version produces sharper findings because the three angles cross-reference each other.

Inputs

The deployed build on staging (or feature branch).
The Feature Brief.
The amigos scenarios.
The Figma frames with state names.
The QA report (if exploratory already run).

Agenda

Time	What
0–5 min	Re-state the moment. PO reads the experience snapshot aloud. "Gal opens the exam Friday afternoon; she has 30 to grade…" The room remembers what the feature is for.
5–20 min	PO walk — uses the feature as the named person would. Does the prediction still seem testable? Does the journey match the brief? Names anything that drifted.
20–35 min	QA walk — runs the Gherkin scenarios manually; does an exploratory pass; runs the accessibility scan. Are the negative cases covered? Any state missing?
35–45 min	Designer walk — checks each frame against Figma, checks the design system tokens, checks content copy. Any visual drift? Any content design gaps?

After the walks: each role gives approve / request changes / block. The decision is unanimous-or-it-doesn't-merge.

Outputs

Three confirmations in the PR/release tracker — recorded as artefacts, not just verbal.
A short merge-readiness note — what shipped, what's known limitations, what's deferred.
(If blocked) named action items with owners.

What good looks like

Each role's confirmation names a specific dimension they checked. PO: "I walked the negative-balance scenario; the new error state matches the brief. Approved." QA: "Five scenarios pass; exploratory found one tooltip cut at 768px; not blocking, filed as BUG-214. Approved." Designer: "Storybook diffs reviewed; one new baseline approved; copy matches the content design guide. Approved."

The three confirmations catch different things. PO catches drift from the brief; QA catches scenario-gap; Designer catches design-system drift. Together they form a complete read; alone they would each miss one third of what matters.

Anti-pattern

One role rubber-stamps because they trust the others. "PO said it's fine, so I'll approve." Now there are only two angles; the third is dark. Fix: each role does their walk independently. Trust is earned by walking, not assumed.

A second anti-pattern: the session becomes a developer's defense. Author argues against every finding; the reviewers back down to keep peace; problems ship. Fix: the reviewers' job is to find; the developer's job is to fix or defer with a named follow-up. Defending isn't an option.

A third: only one or two roles attend. A trio confirmation with only the PO and Developer in the room is two-angle review — and the wallet bug is the kind of thing the third angle (QA) would catch.

Three-confirmation review ​

When ​

Who ​

Time-box ​

Inputs ​

Agenda ​

Outputs ​

What good looks like ​

Anti-pattern ​

See also ​