What does Three Amigos mean?

"Three Amigos" is a collaborative practice in agile software development where three key perspectives -- Business (Product), Development, and Testing (Quality) -- come together to discuss, refine, and align on a user story or feature before development begins. The goal is to build a shared understanding of what needs to be built, why it matters, and how it will be validated.

The term was coined by George Dinwiddie and is closely associated with Behavior-Driven Development (BDD). The practice ensures that requirements are examined from multiple viewpoints before a single line of code is written, dramatically reducing misunderstandings, rework, and defects.

A Three Amigos session is not a formal meeting in the traditional sense -- it is a focused, time-boxed conversation (typically 15-30 minutes per user story) that produces clarity, consensus, and well-defined acceptance criteria.

Business (Product) Perspective

Represented by the Product Owner, Product Manager, Business Analyst, or any stakeholder who understands the business need.

This perspective answers:

• Why are we building this? What problem does it solve?
• Who is this for? What user or customer segment benefits?
• What value does it deliver? How does it impact business metrics?
• What is the priority relative to other work?

The business perspective ensures the team focuses on the right problem and understands the context behind the request. Without this perspective, teams risk building technically correct solutions to the wrong problems.

Development Perspective

Represented by a developer or engineer who will implement the solution.

This perspective answers:

• How can this be built? What technical approach will we use?
• What are the technical constraints or limitations?
• What dependencies exist (APIs, databases, other services)?
• What is the impact on the existing architecture?
• How long will this realistically take?
• What edge cases might we encounter?

The development perspective identifies technical feasibility, highlights risks, and surfaces implementation details that affect scope and timeline. Developers often see implications that are not obvious from a business or testing viewpoint.

Testing (Quality) Perspective

Represented by a QA engineer, tester, or any team member with a quality-focused mindset.

This perspective answers:

• How will we verify this works correctly?
• What are the acceptance criteria?
• What could go wrong? What are the edge cases?
• What happens with invalid inputs, timeouts, or errors?
• How will we test this? (manually, automated, or both?)
• What existing functionality might be affected (regression risk)?

The testing perspective is invaluable because testers are trained to think about what can break. They ask the uncomfortable questions that prevent defects from reaching users.

Before the session

1. Select the stories: choose 2-4 user stories that are candidates for the upcoming sprint or work cycle.
2. Pre-read: share the user stories with all participants ahead of time so they can come prepared with questions and ideas.
3. Time-box: allocate 15-30 minutes per story. Keep the total session under 90 minutes to maintain energy and focus.

During the session

1. Business presents the story: the Product Owner explains the user story, its context, and the expected value.
2. Questions and discussion: all three perspectives ask questions, challenge assumptions, and explore edge cases.
3. Define acceptance criteria: collaboratively write the conditions that must be true for the story to be considered complete. Using the Given-When-Then format (Gherkin) is common but not required.
4. Identify unknowns: if significant unknowns emerge, decide whether a spike is needed before committing to the story.
5. Document the outcome: update the story with the refined acceptance criteria, notes, and any open questions.

After the session

• Update the user story in the team's tracking tool (Jira, Asana, etc.).
• If the team uses BDD, convert the acceptance criteria into executable specifications (Gherkin feature files).
• Flag any stories that need further refinement or spikes before they are ready for development.

User story: "As a customer, I want to reset my password via email so that I can regain access to my account."

Business perspective questions and inputs

• "This is the most common support ticket we receive. Reducing password reset friction would save approximately 200 support hours per month."
• "The email should come from our branded domain, not a generic address."
• "We need to comply with security regulations -- the reset link must expire."

Development perspective questions and inputs

• "We will use our existing email service. The reset token should be a cryptographically secure random string."
• "The token should expire after 1 hour for security."
• "We need to rate-limit requests to prevent abuse -- maximum 3 reset requests per hour per email."
• "Should we invalidate previous tokens when a new one is requested?"

Testing perspective questions and inputs

• "What happens if the user requests a reset for an email that does not exist in our system? We should not reveal whether the email exists (security best practice)."
• "What happens if the user clicks the link after it has expired?"
• "What if the user requests multiple resets -- does only the latest link work?"
• "Does the user remain logged in on other devices after resetting?"
• "What if the email ends up in spam? Do we provide an alternative recovery method?"

Resulting acceptance criteria

Scenario: Successful password reset request Given I am on the login page When I click "Forgot password" and enter my registered email Then I should see a confirmation message regardless of whether the email exists And a reset email should be sent only if the email is registered Scenario: Password reset link expiration Given I have received a password reset email When I click the reset link after 1 hour has passed Then I should see a message that the link has expired And I should be able to request a new reset link Scenario: Rate limiting Given I have requested 3 password resets in the last hour When I request another reset Then I should be informed to try again later

This example demonstrates how the Three Amigos session produces much richer acceptance criteria than any single perspective would generate alone.

Early problem identification

Issues that would typically be discovered during development or testing are identified before coding begins. This is far cheaper -- fixing a misunderstanding in a 20-minute conversation costs almost nothing compared to reworking a feature after days of development.

Shared understanding

All three perspectives leave the session with the same mental model of what needs to be built. This alignment eliminates the "telephone game" effect where requirements degrade as they pass from person to person.

Better acceptance criteria

Acceptance criteria created collaboratively by all three perspectives are more complete, more testable, and less ambiguous than those written by a single person.

Faster delivery

While Three Amigos sessions require time upfront, they save much more time downstream by reducing rework, bugs, and back-and-forth clarifications during development.

Improved quality

By bringing the testing perspective into the conversation early, the team considers edge cases, error handling, and validation scenarios that would otherwise be discovered late (or not at all).

Stronger team culture

Regular Three Amigos sessions build empathy between disciplines. Developers understand business constraints, product people understand technical trade-offs, and testers are valued for their critical thinking rather than treated as gatekeepers.

Three Amigos sessions are the natural precursor to Behavior-Driven Development (BDD). The acceptance criteria produced in a Three Amigos session can be written directly as BDD scenarios using the Gherkin syntax (Given-When-Then), which then become:

1. Living documentation: human-readable specifications that describe system behavior.
2. Executable tests: automated tests that verify the system behaves as specified.
3. Communication artifacts: a shared language between business and technical team members.

Tools like Cucumber, SpecFlow, and Behave execute these specifications as automated tests, creating a direct link between requirements and validation.

"We do not have dedicated testers"

The testing perspective does not require a dedicated QA engineer. Any team member can adopt the quality mindset during the session -- asking "What could go wrong?" and "How will we verify this?" Developers, designers, or even product owners can fill this role. In teams practicing whole-team quality, everyone shares responsibility for quality.

"The sessions take too long"

Time-box strictly: 15-30 minutes per story. If a story generates so many questions that it exceeds the time box, it probably needs to be broken into smaller stories or requires a spike first.

"We cannot get all three perspectives in the room"

Asynchronous Three Amigos can work: the business perspective writes the story and initial criteria, the development perspective adds technical notes and questions, and the testing perspective adds test scenarios and edge cases. However, the synchronous conversation is more effective for building shared understanding.

"Stories still have gaps after the session"

This is normal and expected. Three Amigos reduces gaps significantly but cannot eliminate all ambiguity. Encourage developers to raise questions as they emerge during implementation rather than making assumptions.

Common timing

• During backlog refinement: as part of the regular refinement process, 1-2 sessions per week.
• Before sprint planning: ensure stories are ready before they are selected for a sprint.
• On demand: when a story is complex or ambiguous, request a Three Amigos session before committing to it.

Frequency guidelines

Team maturity	Frequency	Stories per session
New to Three Amigos	Weekly, 60-90 minutes	3-5 stories
Experienced	As needed, 30-60 minutes	2-4 stories
Advanced	Embedded in daily workflow	1-2 stories ad hoc

Must there be exactly three people in a Three Amigos session?

No. "Three Amigos" refers to three perspectives, not three people. A session might include two developers, a product owner, and a QA engineer (four people, three perspectives). What matters is that business, development, and testing viewpoints are all represented.

Is Three Amigos the same as backlog refinement?

Not exactly. Backlog refinement is a broader activity that includes prioritization, estimation, and story decomposition. Three Amigos is a specific technique focused on building shared understanding and defining acceptance criteria for individual stories. Three Amigos sessions can be part of the refinement process.

How does Three Amigos relate to the Definition of Ready (DoR)?

Many teams include "Three Amigos session completed" as one of the criteria in their Definition of Ready. This ensures that no story enters a sprint without having been examined from all three perspectives.

Can Three Amigos work in remote teams?

Yes. Video calls with screen sharing work well for Three Amigos sessions. Collaborative tools like Miro, FigJam, or even a shared document can replace the physical whiteboard. The key is to maintain the interactive, conversational nature of the session rather than turning it into a presentation.

What if business and development disagree during the session?

Disagreements are healthy and expected -- they indicate that the session is surfacing important issues. The product owner has the final say on business priorities and scope, while the development perspective has authority on technical feasibility. If a compromise cannot be reached, a time-boxed spike can provide the data needed to make an informed decision.

Do we need Three Amigos for every story?

Not necessarily. Simple, well-understood stories (e.g., "Change the button color from blue to green") may not benefit from a full Three Amigos session. Focus the practice on stories that involve complexity, ambiguity, or significant risk. As the team matures, they develop a sense for which stories need the conversation and which do not.