Three Amigos Meeting

Definition

The Three Amigos Meeting is a short conversation — usually 15 to 30 minutes — between a product representative, a developer and a tester (the "three amigos") before a user story is committed to a sprint. Its purpose is to surface ambiguity in the story, agree on concrete examples of how it should behave, and align three perspectives that would otherwise collide later in the delivery process. It is one of the highest-leverage agile practices for reducing rework, and one of the least practised.

Where It Comes From

The name is generally attributed to George Dinwiddie, who popularised the practice around 2009 as a lightweight version of the specification workshops used in Behaviour-Driven Development. The technique itself is older — it echoes the specification-by-example approach documented by Gojko Adzic and the acceptance-test-driven development practice associated with Ward Cunningham and Kent Beck. The Three Amigos label stuck because it is simple, memorable, and describes what the meeting actually is.

Why It Matters

Most defects are not coding errors. They are misunderstandings that were locked in early, propagated through the codebase, and only discovered when someone finally read the acceptance criteria and disagreed with the implementation. The Three Amigos meeting catches those misunderstandings while they are still cheap — in a conversation lasting 20 minutes, before anyone has written a line of code. It is the classic economics of defect cost: catch it in requirements and it costs one; catch it in production and it costs a thousand.

Real-World Example

On a healthcare booking platform, a user story read "Users can cancel a booking up to 24 hours before the appointment." The developer estimated three points and the team accepted it into the sprint. Two days later the tester queried what "24 hours" meant — clock hours or business hours? The product owner assumed business hours. The developer had built clock hours. Rework consumed a further two days. On the same team, a subsequent story went through a 20-minute Three Amigos before commitment. The three participants agreed that "cancellation" meant the appointment slot returned to the pool, that cancellations within 24 hours were declined with an explanatory message, and that the timezone for the 24-hour window was the patient's local time. All three details would otherwise have surfaced in test, in review, or in production. The story shipped clean on the first pass.

How to Run It

1. Time-box it. 15 to 30 minutes. Longer and it becomes a workshop; shorter and it becomes theatre.
2. Three people, three perspectives. Product asks "why do we want this?", developer asks "how would we build it?", tester asks "how would we know it worked?"
3. Work through concrete examples, not abstractions. "A user with an appointment at 2pm tomorrow tries to cancel at 3pm today — what happens?"
4. Capture acceptance criteria in Given-When-Then form for the examples that came up — these become the acceptance tests.
5. Identify what you don't know and either resolve it in the meeting or flag the story as not ready.
6. Do it before commitment, not during the sprint. Once a story is committed, the Three Amigos has missed its window.

Practical Lessons Learned

• The tester is the most important amigo. They are the one asking "how would we know?" — the question that most reliably surfaces ambiguity.
• Async does not work as well as synchronous. Slack threads about acceptance criteria take longer and produce worse alignment than a 20-minute call.
• Small stories may skip it; complex stories should never skip it. A one-line bug fix does not need three amigos; a workflow change does.
• Product owners resist it at first because it looks like extra work. It is the cheapest work on the whole delivery.
• Meeting fatigue is real. Batch three stories into one 45-minute session rather than three separate 20-minute meetings.

Expert Tips

• Anchor every conversation in a concrete user example rather than a general requirement. "For patient Anna, at 2pm tomorrow…" not "for a patient."
• Write the acceptance criteria in the ticket during the meeting, not afterwards. If it does not get written down in the meeting, it did not happen.
• Involve a fourth amigo — design or ops — when the story warrants it. The three amigos label is a floor, not a ceiling.
• Rotate developers and testers so knowledge does not concentrate in the same pair.
• Kill stories that come out of the meeting still unclear. They are not ready for commitment.

Common Mistakes

• Running the meeting after commitment, when the cost of change is already high.
• Product owner explains, developer nods, tester silent. That is not a conversation.
• Skipping the concrete examples and staying in the abstract.
• Not writing anything down.
• Treating it as a status meeting rather than a design conversation.
• Skipping it because "the story is small" when the story is actually load-bearing.

Key Takeaways

• The Three Amigos is a pre-commitment conversation between product, dev and test.
• Its purpose is to surface ambiguity while it is still cheap.
• Concrete examples beat abstract discussions.
• Acceptance criteria in Given-When-Then form become the acceptance tests.
• Time-boxed, written down, batched sensibly, non-negotiable for load-bearing stories.

Related Concepts

Interlocks with Definition of Ready, Acceptance Criteria, Backlog Refinement, Test-Driven Development, and Story Slicing. Templates and facilitation guides at PMMilestone.org.