The Three Amigos Meeting: How QA, Dev and Product Agree Before Coding
Thirty minutes, three perspectives, one story: a practical agenda, the questions to ask, and how to turn the outcome into test cases.
For agile teams, Scrum Masters, product owners and QA leads who want every story agreed before development starts.
What Is the Three Amigos Meeting?
The Three Amigos is a short meeting where three perspectives, business, development and testing, review one user story together before development starts and agree its rules, examples and acceptance criteria. It is also called "tres amigos" or a specification workshop.
It is shift-left testing in its most practical form: questions a tester would ask after the code is written get answered while the story is still a few sentences. The wider practice is covered in the shift-left section of Agile QA Strategy.
Who Attends and What Each Brings
Product
Development
Testing
The name describes three perspectives, not a headcount. A designer or security specialist can join when the story needs them.
When to Hold It
- During backlog refinement, one or two sprints before the story is planned.
- One story per session, so the discussion stays concrete.
- When the story has a title, a user and a goal; the meeting fills in the rest.
- Again, briefly, if the story changes significantly before development starts.
A 30-Minute Three Amigos Agenda
| Minutes | Step | Led by | Output |
|---|---|---|---|
| 0 to 5 | Present the story and its goal | Product | Shared understanding of the user and the value |
| 5 to 15 | Agree the rules and walk through examples | Everyone | Rules, each with one or more concrete examples |
| 15 to 22 | Explore edge cases and failure paths | Testing | Negative and boundary examples, risks |
| 22 to 27 | Check constraints and size | Development | Technical notes, a split if the story is too big |
| 27 to 30 | Confirm criteria and open questions | Everyone | Acceptance criteria, questions with owners |
Questions Each Role Should Ask
| Role | Questions |
|---|---|
| Product | Who is this for, and what problem does it solve? What is out of scope for this story? What does success look like after release? Which rule matters most if time runs short? |
| Development | Which systems or services does this touch? Is any data migration needed? What is the simplest version we could ship first? Are there performance or security limits to respect? |
| Testing | What happens with empty, invalid or maximum input? What if the user is not allowed to do this? What if the action is repeated or interrupted? How will we know it works in production? |
Example Mapping: A Simple Structure for the Discussion
Example Mapping keeps the conversation focused. Write the story at the top, then add three kinds of notes: rules the story must follow, examples that show each rule in action, and questions nobody can answer yet. Many examples under one rule usually means the rule needs splitting; many questions means the story is not ready.
| Rule | Examples |
|---|---|
| Cancellation takes effect at the end of the billing period | Monthly plan cancelled on day 10 stays active until day 30; on day 31 the account moves to the free plan |
| A cancelled subscription can be resumed before the period ends | Cancel on day 10, resume on day 20: billing continues with no gap. Resume on day 31: not offered, the user subscribes again |
| Only the account owner can cancel | Owner sees Cancel; a team member sees "Ask your account owner to cancel" |
Open question
What the Meeting Produces
- Acceptance criteria the whole team agrees with
- Concrete examples for each rule, including failure paths
- Open questions, each with an owner and a date
- A smaller story, if the discussion showed it was too big
- Test ideas QA can start from straight away
The rules and examples become the acceptance criteria, in whatever format your team uses. Formats such as Given / When / Then are covered in Acceptance Criteria: The Foundation of Effective QA.
Habits That Keep the Meeting Useful
- Keep to one story and a fixed time box; book a second session rather than running long.
- Write the rules and examples down during the meeting, where everyone can see them.
- Decide what the story should do, and leave how to build it to development.
- Invite the people who will build and test the story, so the agreement travels with the work.
- Use concrete values in examples: dates, amounts and user types, not "some data".
From the Meeting to Test Cases in Evaficy Smart Test
The agreed criteria are a ready-made input for test case generation, so QA can have reviewed test cases before development finishes.
- Paste the agreed criteria into a Requirement or Acceptance Criteria custom field. Both are strict: every generated case must respect them, and the set must cover them.
- Generate one test type per pass, up to 10 cases each and usually around 7: for example Functional for the rules, then Boundary Edge Case for dates and limits.
- Save the result as a scenario named after the story key, so the cases are easy to find from the ticket.
Story text from Jira is copied and pasted in; the workflow is shown step by step in How to Automate Manual Test Case Writing from Jira Acceptance Criteria.
Let the product amigo confirm the cases
Some teams generate a draft set before the meeting, so the tester arrives with concrete edge cases to raise. Each generation counts toward your plan's AI quota, so this works best for larger stories. For the rules themselves, Boundary Edge Case is the type that surfaces limits worth discussing.
Common Questions
What does "tres amigos" mean in agile?
It is another name for the Three Amigos meeting. "Amigos" means friends in Spanish, and the name refers to the three perspectives (business, development and testing) that review a user story together before development starts.
Is the Three Amigos the same as backlog refinement?
They are closely related. Backlog refinement is the wider activity of preparing the backlog, often with the whole team. A Three Amigos session is a focused part of it: three perspectives working through one story in detail until its rules and acceptance criteria are agreed.
How long should a Three Amigos meeting last?
Around 25 to 30 minutes per story. If a story needs much longer, it is usually a sign that it should be split or that a question needs research first.
Who runs the Three Amigos meeting?
Usually the product owner or business analyst brings the story, and anyone can facilitate. Many teams let the tester keep time and write down the examples, since they will turn them into test cases afterwards.
Does it have to be exactly three people?
No. The name refers to three perspectives. A designer, a security specialist or a second developer can join when the story needs them, as long as the group stays small enough to decide quickly.
Can a Three Amigos meeting be done remotely or asynchronously?
Yes. Remote sessions work well with a shared board for rules, examples and questions. An asynchronous version also works: one person drafts the criteria and examples, and the other two comment and agree in writing before development starts.
Key Takeaways
- The Three Amigos brings business, development and testing together on one story before development starts.
- It is three perspectives, not three people, and it takes about 30 minutes per story.
- Each role asks its own questions: why and scope, how and constraints, what if and how to check.
- Example Mapping organises the talk into rules, examples and open questions.
- The output is agreed acceptance criteria, concrete examples, and questions with owners.
- Paste the agreed criteria into a Requirement or Acceptance Criteria field to generate test cases, then let the product owner validate them.
Turn your next Three Amigos outcome into test cases
Create a free account, paste the agreed criteria into the Requirement field and review the cases with your team. The Basic plan includes 5 AI generations.
Create your free account