BDD Foundations
Three Amigos: Dev, QA, BA Collaboration
Three Amigos: Dev, QA, BA Collaboration
BDD is most valuable when it changes how the team communicates — not just how tests are written. The "Three Amigos" practice is where that change actually happens.
Who's in the Room
- Product Owner / BA: knows the business requirement and the "why"
- Developer: knows the technical constraints and what's hard vs. easy to build
- Tester: knows the edge cases, failure modes, and what usually goes wrong
The session goal: write concrete examples that define "done" for the story, before any code is written.
Walking Through a Session
Story: "As a user, I want to reset my password"
A Three Amigos session turns that one-line story into concrete scenarios:
Scenario: Successful password reset
Given my account email is "user@test.com"
When I request a password reset for "user@test.com"
And I follow the reset link in the email
And I set a new password "NewPass@123"
Then I should be able to log in with "NewPass@123"
Scenario: Reset link expires after 1 hour
Given I requested a password reset 2 hours ago
When I follow the old reset link
Then I should see "This reset link has expired"
Scenario: Reset link is single-use
Given I successfully reset my password
When I follow the same reset link again
Then I should see "This reset link has already been used"
The expiry and single-use scenarios rarely appear in the original story — they surface because a tester was in the room asking "what happens if...". These become the acceptance criteria, agreed by all three roles before development starts.
Fitting It Into a Sprint
| Sprint Phase | Activity |
|---|---|
| Backlog refinement | Three Amigos — write scenarios for upcoming stories |
| Sprint planning | Scenarios inform estimation — more scenarios usually means more complexity |
| Development | Dev implements against the agreed scenarios; QA automates them |
| Sprint review | The feature files double as demo material |
Common Failure Modes
Skipping the conversation, keeping the artifact: A dev or tester writes scenarios alone and shares them for "approval." This produces a document, not shared understanding — the whole point of Three Amigos is the discussion, not the Gherkin file it produces.
Too many scenarios: Focus on business rules and meaningfully different edge cases, not every possible permutation. 3–5 scenarios per story is usually the right range.
No BA/PO in the room: Without the business perspective, dev and QA can agree on technically sound scenarios that miss the actual business intent.
💬 Discussion
Does your team do Three Amigos meetings or something equivalent? If not, what problems arise from the absence of that conversation?
What is the primary goal of a Three Amigos session?
Next Lesson
Given/When/Then Writing Rules