Writing Gherkin with Stakeholders — Three Amigos

You can write technically correct Gherkin entirely on your own. You can wire up step definitions, hook up Selenium, and produce green reports — and still be building the wrong thing. The Three Amigos practice is what prevents that. It is not a Cucumber feature; it is a meeting format. And it is the most important thing in this chapter.

What the Three Amigos actually is

Three Amigos is a short, structured conversation that happens before development starts on a user story. The three perspectives in the room are:

• Product Owner — "Here's what the business needs. Here's the user story."
• Developer — "Here's how I'm thinking about building it. Here are the constraints."
• Tester — "Here's what could go wrong. Here are the edge cases you haven't thought of yet."

The output is a set of concrete Gherkin scenarios that all three people have reviewed and agreed represent the requirement correctly. Those scenarios become the acceptance criteria — and eventually the automated test suite.

The meeting is typically 15–30 minutes per story. Not every story needs it. Focus on complex, risky, or ambiguous stories. Simple CRUD operations with no edge cases can skip it.

A Three Amigos session in action

Story: "As a registered user, I want to reset my password so that I can regain access to my account."

Round 1 — PO presents:

"Users will click 'Forgot Password' on the login page, enter their email, and receive a reset link. They click the link, enter a new password, and they're done."

Round 2 — developer asks:

"How long does the reset link stay valid? Can a user request multiple links? What are the password requirements for the new password?"

Round 3 — tester asks:

"What happens if the email address doesn't exist in our system? What if the user tries to use the same link twice? What if the new password is the same as the old one? What if the user requests 10 reset links in 5 minutes?"

The responses shape the specification:

• PO: "The link expires after 24 hours. Same link can't be used twice."
• Developer: "We'll rate-limit: maximum 3 reset requests per hour per email."
• PO: "If the email doesn't exist, show a generic 'if that email is registered, you'll receive a link' message — security reasons."

The resulting Gherkin:

Feature: Password Reset
 
  Scenario: Successful password reset with valid email
    Given a user account exists with email "alice@test.com"
    When the user requests a password reset for "alice@test.com"
    Then a reset link should be sent to "alice@test.com"
    And the link should expire after 24 hours
 
  Scenario: Reset request for unregistered email shows generic message
    Given no account exists with email "unknown@test.com"
    When the user requests a password reset for "unknown@test.com"
    Then the user should see "If that email is registered, you will receive a reset link"
 
  Scenario: Expired reset link cannot be used
    Given a password reset link was created 25 hours ago for "alice@test.com"
    When the user clicks the reset link
    Then the user should see "This reset link has expired"
 
  Scenario: Reset link can only be used once
    Given a password reset link has already been used for "alice@test.com"
    When the user clicks the same reset link again
    Then the user should see "This reset link has already been used"
 
  Scenario: Rate limiting prevents more than 3 reset requests per hour
    Given "alice@test.com" has already requested 3 resets in the last hour
    When the user requests another password reset for "alice@test.com"
    Then the user should see "Too many reset requests. Please try again later."

Five scenarios. None of them existed before the meeting. Two of them (rate limiting, generic unregistered message) would have been missed entirely if a developer or tester had written the Gherkin alone.

QA's role: the edge case machine

In a Three Amigos session, the tester's job is to ask the questions that expose ambiguity. A useful mental framework: for every story, ask these five categories of questions:

1. What could go wrong? (invalid inputs, network failures, expired data)
2. What are the boundaries? (minimum/maximum values, time limits, count limits)
3. What is the security implication? (can users see each other's data, brute-force risks)
4. What is the concurrent case? (two users doing the same thing simultaneously)
5. What is the empty/null case? (empty form, no results, no items in cart)

Most teams that "do BDD" never ask these questions until the code is written — and then discover the edge cases as production bugs.

Running Three Amigos in practice

Timing: Sprint planning or backlog refinement. Before the sprint starts, not during development.

Duration: 15–30 minutes per story. If it takes longer, the story is too large or too poorly defined — split it.

Preparation: the PO should prepare the user story and any wireframes. The tester should have read the story and come with questions ready. The developer should have thought about technical constraints.

Output: a list of Gherkin scenarios (rough draft acceptable — they'll be cleaned up). Agreement from all three that the scenarios cover the requirement. No open ambiguities.

Not every story needs it: simple, well-understood stories (minor UI copy changes, config updates) can skip Three Amigos. Invest the time in complex, risky, or cross-functional features.

The collaboration flow

⚠️ Common mistakes

• Skipping Three Amigos because "it slows us down." The perceived slowdown is 30 minutes per story. The actual cost of skipping it is the edge case discovered in production, the rework sprint, and the postmortem. The ROI of Three Amigos is measured in bugs never written.
• Holding Three Amigos after development starts. If the developer has already written the code, the conversation is a review, not a collaboration. The power is in shaping requirements before implementation is committed.
• Only the tester writing the Gherkin. When the tester writes scenarios alone and hands them to developers to implement, you have a testing tool, not a BDD practice. The shared ownership of the Gherkin is what makes it a shared understanding artifact.
• Trying to write perfect Gherkin in the meeting. The Three Amigos session produces rough scenario outlines. Cleaning the language and making the steps reusable is a follow-up task — don't let perfect be the enemy of done in the session itself.

🎯 Practice task

Run a simulated Three Amigos session — no code needed. 30 minutes.

1. Pick a user story from any app you've tested or used: "As a user, I want to change my email address" or "As a buyer, I want to save items to a wishlist."
2. Write down what a Product Owner would say about the happy path (2–3 sentences).
3. Write 3 questions a developer would ask about constraints or technical decisions.
4. Write 5 questions a tester would ask about edge cases, errors, and security (use the five categories from this lesson).
5. Answer each question (make reasonable assumptions) and write the resulting Gherkin scenarios. You should produce at least 4–6 scenarios, including at least two that only emerged from the edge-case questions.
6. Stretch: take the feature files you've written in previous lessons and audit them. How many of your scenarios cover edge cases vs happy paths? What edge cases are missing that a Three Amigos session would have surfaced?

Next lesson: turning Cucumber feature files and reports into living documentation your stakeholders actually use.