Running the Three Amigos
The Three Amigos—developer, QA, and product analyst—sit together before code is written. They ask hard questions, discover hidden requirements, and build shared understanding. As the Test Lead, you facilitate this conversation.
1 The Hook — Why This Matters
In 2022, an Auckland logistics team was tasked with building a "customer notification system." The product manager wrote: "Notify customers when their shipment is out for delivery." Sounds clear. The developer built it. The QA wrote tests. The system shipped.
Three days later, complaints flooded in. Some customers were getting notifications at 2 AM. Some were not getting notifications at all. Some got notified twice. Turns out, the requirements were far more complex: notifications needed to respect customer timezone preferences, batch messages for multi-item orders, and only send between 8 AM and 8 PM. None of this was mentioned in the original brief. The product manager assumed developers would know. QA found the gap in testing, but only after the product was live. Two-day emergency fix. Customer trust damaged.
The Three Amigos meeting would have caught this in an hour. Developer, QA, and PM sitting together, asking concrete questions, before any code was written. "What time should the notification go out? What if the customer is in a different timezone? What if they have multiple orders?"
2 The Rule — The One-Sentence Version
The Three Amigos is a 30-60 minute conversation where dev, QA, and product discover requirements together before development starts, turning vague specifications into concrete acceptance criteria.
The three perspectives matter: The Product Analyst/BA knows what the customer needs and why. The Developer knows what's technically feasible and spots implementation risks. The QA/Test Lead asks "what if" questions and thinks about edge cases. No single person has all the answers. Together, they do.
3 The Analogy — Think Of It Like...
A architect, a builder, and a safety inspector reviewing the blueprints before construction starts.
The architect has the vision. The builder knows what's realistic to construct and spots technical problems. The safety inspector asks "what if there's an earthquake?" or "what if the foundation settles unevenly?" None of them can make those decisions alone. If you skip this conversation and start building, you'll discover the flaws mid-construction when fixes are expensive. Three Amigos is the pre-build walkthrough.
4 Watch Me Do It — A Real Session
Let's walk through a real Three Amigos session for a payment refund feature at a NZ e-commerce company. I'll show you the conversation, the discoveries, and how they translate into acceptance criteria.
Pre-Session: The Brief
The PM brings a user story: "As a customer, I want to request a refund, so I can get my money back if I'm not happy with my purchase."
It sounds simple. But it's not. That's why we need Three Amigos.
During the Session: The Conversation
Test Lead (facilitator): "Let's walk through a customer requesting a refund. Jane bought a jacket for $80 two weeks ago. She wants her money back. What happens first?" Product Manager: "Jane clicks 'Request Refund' on her order page, selects a reason, and submits it. We show a confirmation message." Developer: "Wait. Can she refund a partial order? If she bought two items, can she refund just one?" PM: "Good question. Yes, partial refunds should work." Test Lead: "OK. How much time does Jane have to request a refund? If she bought it two weeks ago, can she request at week four? Six months?" PM: "Our policy is 30 days. After that, no refunds." QA: "What happens if she tries after 30 days?" PM: "The refund button should be disabled or show a message." Developer: "Do we check the order date or the delivery date? If shipped but not delivered, does the 30 days start from order or delivery?" PM: "From delivery. But some items haven't shipped yet. How do we handle that? Is the 30 days per item?" Test Lead: "That's a rule we need to clarify. Let me note this down." Developer: "When we process the refund, where does the money go? Back to the original payment method? How long does it take?" PM: "Back to the card. Usually 2-5 business days depending on the bank." QA: "Can Jane track the refund status? Will she get a confirmation email?" PM: "Yes, an email. But the status page—can we just show 'Refunded'? Or do we show 'Pending Refund' while the bank processes it?" Developer: "That depends on our payment gateway. I need to check if they send us a webhook when the refund actually clears on the customer's card." QA: "What if the refund fails? Card closed, wrong bank details, something on the payment gateway side?" PM: "We should try again. But how many times? And do we notify Jane if it fails?" Test Lead: "Let's document this. We have three error cases: gateway error, customer card invalid, customer closed account. For each, we need: what the user sees, what happens in the background, and what the support team sees."
After the Session: The Acceptance Criteria
The conversation above generated these concrete acceptance criteria that did NOT exist in the original user story:
Feature: Customer Refund Requests Scenario: Customer requests partial refund within 30 days Given a customer has an order with 2 items delivered 10 days ago And the total order was $100 (Item A: $40, Item B: $60) When the customer requests a refund for Item A only Then the customer sees: "Refund of $40 will be sent to [card ending in 1234]" And an email is sent: "We've received your refund request (Order #123456)" And the refund status shows "Pending" for 2-5 business days Scenario: Refund button is disabled after 30 days Given a customer has an order delivered 31 days ago When the customer visits the order page Then the "Request Refund" button is disabled And a message shows: "Refunds are available for 30 days after delivery" Scenario: Refund fails because card is closed Given a refund of $40 is requested and pending And the customer's card has been closed When the payment gateway attempts to process the refund Then the refund status changes to "Failed" And the customer receives an email: "We couldn't process your refund" And the customer can choose an alternate payment method And support is notified so they can follow up Scenario: Customer can track refund status Given a refund request was submitted 3 days ago When the customer visits the order page Then the status shows "Refund in progress" with expected completion date And a link shows "Refund History"
5 When to Use It / When NOT to Use It
✅ Run Three Amigos when...
- A new feature or user story is being started
- Requirements are ambiguous or complex
- Cross-team coordination matters (payment, compliance, integrations)
- The team has had past misunderstandings on similar features
- The feature touches multiple systems or databases
- Customer impact is high (refunds, data loss, security)
❌ Skip Three Amigos when...
- Requirements are fully specified (detailed, tested, approved)
- It's a simple bug fix or UI tweak
- The work is a pre-approved refactoring or tech debt
- You're fixing a documented issue with clear acceptance criteria
- The developer or QA is unavailable (don't skip, reschedule)
6 Common Mistakes — Don't Do This
🚫 Running Three Amigos as a presentation, not a discussion
I used to do: PM talks for 20 minutes, dev nods, QA takes notes.
Actually: Three Amigos is a conversation. Stop every 2-3 minutes. Ask questions. Disagree. The meeting should feel like a debate, not a briefing. If only one person is talking, you're not doing Three Amigos.
🚫 Skipping when requirements seem "obvious"
I used to think: "Jane requests a refund. What's complex about that?"
Actually: The word "request" glossed over five implementation decisions: time window, partial vs full, payment method, error handling, status tracking. Always run it. The obvious parts take 10 minutes. The hidden parts take 30.
🚫 Missing the developer or QA (only PM + one person)
I used to do: "The dev is busy, let's just PM and QA talk."
Actually: Without the developer, you'll miss technical risks. Without QA, you'll miss edge cases. All three matter. Reschedule if someone can't attend.
🚫 Not documenting the outcomes
I used to do: Verbal discussion, no notes, assumptions lost.
Actually: Record everything: rules discovered, examples, open questions, open decisions. Store it in Jira or Confluence. Share with the team. This becomes your acceptance criteria and test cases.
7 Now You Try — Facilitator's Challenge
Scenario: You're running Three Amigos for a password reset feature. The PM says: "Users should be able to reset their password if they forgot it." You're the facilitator. Write down five questions you would ask to uncover hidden requirements.
Your goal: transform vague spec into concrete rules.
Five questions a facilitator would ask:
- Time window: "How long is the reset link valid? If a user receives it but waits 2 hours, then tries to use it, what happens?"
- Security: "Can someone request a password reset for another user's email address to harass them? What checks do we have?"
- Recovery: "If the user doesn't receive the reset email, what do they do? Is there a backup recovery method?"
- Session management: "If I'm already logged in and request a password reset, do I get logged out? Or can I still use the old password?"
- Error cases: "What if the user clicks the reset link but enters mismatched passwords? What's the error message? Can they try again?"
Your questions don't need to be identical, but they should probe time windows, security, error handling, and edge cases. These questions shape the acceptance criteria.
8 Self-Check — Can You Actually Do This?
Click each question to test your facilitation readiness. If you answer all three correctly, you're ready to run your first Three Amigos.
Q1. What's the role of the QA in Three Amigos?
To ask "what if" questions and uncover edge cases. The QA thinks about error scenarios, boundary conditions, and what happens when something goes wrong. The dev thinks about feasibility, the PM thinks about customer value, but the QA is the voice of "what breaks this?" That perspective is critical to producing complete acceptance criteria.
Q2. How long should a Three Amigos session take?
30 to 60 minutes for most features. A simple CRUD feature might take 30 minutes. A complex payment flow might take 90 minutes. If it goes over 2 hours, you're either over-detailing or the scope is too large (split into smaller stories). Keep it focused: one user story, one sitting, one clear set of acceptance criteria as the output.
Q3. What should you document from a Three Amigos session?
The acceptance criteria (Gherkin scenarios or rule/example pairs), assumptions you made, and open questions that need follow-up. Post-it notes or a whiteboard photo is not enough. Store the outcomes in Jira/Confluence so the whole team can see them. This becomes the contract between product, dev, and QA.
9 Interview Prep — Common Questions
Q. "How do you handle disagreement in a Three Amigos session?"
If the dev says "that's not feasible," the PM says "but the customer needs it," and QA is unsure which way to test, you have a disagreement. Don't force consensus. Instead: (1) Acknowledge the disagreement, (2) Document both sides, (3) Escalate to the tech lead or product manager for a decision, (4) Continue with the decision made. A documented decision is better than a hidden misunderstanding that surfaces after code is written.
Q. "Can you run Three Amigos remotely or async?"
Synchronous remote (Zoom call) works fine. Everyone shares a Miro board or Google Doc to build examples together. Async (email, comments) is much harder because the conversation loses its momentum and clarifications get lost. If your team is distributed, insist on a 45-minute Zoom call. It's worth the synchronous meeting cost.
Q. "What if the developer or QA isn't available for the meeting?"
Reschedule. Seriously. Running Three Amigos with only two people defeats the purpose. If the dev can't make it because they're in production firefighting, wait until they're available. A one-hour delay in the meeting is better than a week of rework because critical perspectives were missing.
Q. "How do you measure if Three Amigos is working?"
Track: (1) Bugs found in QA vs production (should go down), (2) Rework due to misunderstood requirements (should go down), (3) Time from "story ready" to "story in test" (should go down because dev and QA aligned faster), (4) Team satisfaction (devs report fewer surprises). After 3 months of running Three Amigos consistently, you should see measurable improvement in these metrics.
Q. "What's the difference between Three Amigos and a requirements review?"
A requirements review is a checklist: is the story clear, testable, estimable? Three Amigos is deeper: it's a discovery conversation where the team collaborates to build the story together, asking questions the PM didn't anticipate. Requirements review happens after Three Amigos and is much faster because the hard questions are already answered.