Four amigos
Before a story is built, four perspectives look at it together:
- Product owner — what is wanted, and why
- Developer — what is feasible, and at what cost
- Quality engineer — how it will fail, and how anyone would know
- UX designer — what the person sees, decides and feels
The value is not in the meeting. It is in the fact that the four perspectives usually surface different, incompatible readings of the same sentence, and that surfacing costs fifteen minutes now and a sprint later.
Why four and not three
Section titled “Why four and not three”The practice is commonly run with three: product owner, developer, quality engineer. For anything with a user interface, that room reliably misses an entire class of question — not because the three are careless, but because none of them owns it.
The three ask what must be true. The designer asks what does the person see when it is not — and that second question is where interfaces actually fail.
| Seat | Asks | Would not think to ask |
|---|---|---|
| Product owner | Is this what we want? | Whether the fifth error in a row is survivable |
| Developer | Can we build it, and what does it cost? | What the empty state says |
| Quality engineer | How will it fail, and how will we know? | Whether the failure is comprehensible to the person who hits it |
| UX designer | What does the person see, decide and feel here? | Often the data-model constraints — which is why the other three are there |
Four is the ceiling. At five the session becomes a review, and reviews produce comments rather than decisions.
What the designer brings into the room
Section titled “What the designer brings into the room”Not screens. Two things the other three cannot supply:
The journey. They ran journey mapping, so they know what the person was doing before this story and what they need next. That is the context in which “is this story complete” has an answer.
The design system they already work in. This is the part that makes the session fast rather than slower. When someone asks “what happens when there are none of these”, the designer usually answers the system already has an empty state for a list, and it looks like this — and the question closes in ten seconds instead of becoming a design task.
That is the practical return on the contracts being established inputs rather than things this session invents: most of what the room discovers is already answered, and the discussion narrows to what genuinely is not.
When it runs
Section titled “When it runs”Whenever a story is about to be opened — typically as the first ten minutes of example mapping, which is the same four people and the natural container for the conversation. Running them separately duplicates the room.
What it produces
Section titled “What it produces”Shared understanding, which is not an artefact and cannot be reviewed — so judge the session by what it changed instead:
- a story split, because the four readings turned out to be four stories;
- a red card, because a question nobody could answer got written down instead of assumed;
- a state card, because “what if there are none” had no answer in the design system either;
- a contract change request, because the story genuinely needs something the established contracts do not cover;
- an estimate withdrawn, because it was made on the wrong reading.
A session that changes nothing is a session where somebody was not really in the room.
The anti-pattern it replaces
Section titled “The anti-pattern it replaces”The refinement meeting where the product owner presents. Eight people, one speaking, seven waiting for the part that concerns them. It has the shape of a conversation and the information flow of a document — which is the definition of a handover with extra steps.