Most teams have run a Three Amigos session. Most teams have also watched it dissolve into a 90-minute requirements recap with a few sticky notes and no scenarios anyone can actually automate. The session format isn't broken — the execution is. The difference between a workshop that ships executable specifications and one that produces vague bullet points is almost entirely about preparation and constraint.

The technical problem is concrete: when business analysts, developers, and testers enter a room (or a Zoom) without a shared vocabulary or a forcing function, conversation drifts toward UI flows and edge-case cataloguing rather than behavior specification. You leave with a wall of acceptance criteria that a developer interprets one way and a tester interprets another — and the mismatch surfaces in production, not in review.

By the end of this article you'll have a repeatable workshop structure, a Given-When-Then discipline that keeps scenarios automatable, and a short list of failure modes that even experienced BDD teams hit. The patterns here apply whether you're running Cucumber-JVM 7, Behave, or SpecFlow.

What the Three Amigos Review Is Actually Solving in BDD

The Three Amigos is a specification workshop, not a planning ceremony and not a test-case review. Its job is to surface ambiguity before a story is coded — specifically, to find the cases where the business analyst's mental model, the developer's implementation plan, and the tester's risk map diverge. Those divergences are the bugs that will be filed in three sprints. The session makes them visible now, when they cost nothing to fix.

In a BDD architecture, the output of a Three Amigos session is a set of concrete, automatable scenarios written in Gherkin — not acceptance criteria prose, not a test plan, and not a decision log. Those scenarios become the living specification: the artifact that a Cucumber runner or Behave suite will execute against the system. If a scenario can't be automated as written, it wasn't specific enough, and the session isn't done. That constraint is the forcing function that separates useful workshops from expensive conversations. For a deeper look at what makes these sessions actually productive, the patterns in structuring amigos sessions for real output are worth keeping alongside this guide.

Running the Workshop: Structure, Given-When-Then Syntax, and Output Discipline

Start with a time-box: 45 minutes per story, hard stop. If you can't specify a story's core behaviors in 45 minutes, the story is too large. Split it first. Assign three roles explicitly — one business/product voice, one developer, one tester — and rotate facilitation so no single voice dominates. The facilitator's job is to convert every "it should..." statement into a scenario candidate, not to drive the feature direction.

Given-When-Then Syntax: The BDD Definition That Actually Constrains You

Given-When-Then is not a documentation format — it's a constraint language. Given describes the system state before the action. When describes exactly one user or system action. Then describes the observable outcome. When a When clause contains "and then" or spans two sentences, you have two scenarios. Enforce this at the keyboard, not in review.

# Weak — written in the session without discipline
Scenario: User checkout
  Given the user has items in their cart
  When they complete checkout and payment is processed
  Then the order is confirmed and an email is sent

# Strong — split at the When, state made explicit
Scenario: Order confirmation on successful payment
  Given a registered user has 2 items in their cart
  And the payment gateway is available
  When the user submits a valid Visa card ending in 4242
  Then the order status is "confirmed"
  And an order confirmation email is queued within 5 seconds

The second version is automatable with Playwright or Selenium 4 against a real UI, or with a Pytest fixture hitting an API directly. The first version requires a developer to make four silent decisions before writing a single step definition. Those silent decisions are where requirements drift lives.

Workshop Artifacts: What You Leave With

The session should produce three artifacts: a .feature file draft (even a rough one), a short list of out-of-scope edge cases deferred to a separate story, and any open questions with named owners and a resolution deadline. The feature file draft doesn't need to be merge-ready — it needs to be specific enough that a developer can write step definitions without asking follow-up questions. Use a shared editor (VS Code Live Share, a Confluence page with code blocks, or even a Gist) so the Gherkin is the record of the meeting, not a summary written afterward.

# Feature file skeleton produced in-session
Feature: Payment processing at checkout
  As a registered customer
  I want to complete a purchase with a saved card
  So that I don't re-enter payment details on every order

  Background:
    Given the user "alice@example.com" is authenticated
    And the product catalogue service is healthy

  Scenario: Successful charge with a saved card
    Given Alice has a Visa card ending in 4242 saved to her profile
    When she places an order for SKU "WIDGET-001" at £29.99
    Then the payment provider receives a charge request for £29.99
    And the order record has status "paid"

  Scenario: Declined card triggers order hold
    Given Alice has a card ending in 0002 flagged as declined by the gateway stub
    When she attempts to place the same order
    Then the order record has status "payment_failed"
    And Alice sees the message "Your card was declined. Please update your payment method."

Notice the Background clause — it removes duplicated Given steps and makes the scenarios read cleanly without hiding shared preconditions. A team running Cucumber-JVM 7 or SpecFlow 4 will get this for free; Behave handles it identically. Run time on this feature file against a stub payment gateway: under 8 seconds. The same coverage written as manual test cases took 25 minutes to execute per sprint. That gap compounds.

Where Three Amigos Sessions Break Down for Experienced Teams

The most common failure mode isn't running the session wrong — it's running it too late. Teams that schedule Three Amigos as a pre-sprint ritual rather than a mid-refinement activity arrive with stories that are already scoped, estimated, and half-designed. The developer has a mental implementation. The tester has a draft test plan. The session becomes a review of prior decisions rather than a discovery of ambiguity. Fix this by triggering the session at the moment a story moves from "idea" to "ready for refinement" — before estimation, not after.

The second failure is scenario inflation: the tester's instinct is to cover every edge case, and without a facilitator enforcing scope, a 45-minute session produces 18 scenarios for a two-point story. Most of those scenarios test implementation details rather than business behavior. The rule of thumb: if a scenario requires knowledge of the database schema or a specific HTTP status code to write, it belongs in a unit or integration test, not in a feature file. Keeping scenarios as the living specification means they must stay readable by non-engineers — that constraint self-limits scope inflation better than any process rule.

What Most Teams Still Get Wrong About the Three Amigos Format

The persistent myth is that Three Amigos is a QA gate — a checkpoint where testers sign off on requirements. It isn't. The tester's role in the session is to ask "what could go wrong?" and "what state makes this fail?" — not to approve the story or own the scenarios. When testers feel responsible for scenario completeness, they over-specify. When developers feel like passive recipients of scenarios, they under-invest in step definition design. The session works when all three roles are co-authoring, not when one role is presenting to the other two.

A related misconception is that AI tooling — ChatGPT, Claude, Cursor — can replace the session by generating Gherkin from a ticket description. It can generate syntactically valid Gherkin quickly. It cannot surface the disagreement between what the BA wrote, what the developer planned to build, and what the tester knows will break in staging. That disagreement is the entire value of the session. AI-generated scenarios also carry a specific risk: step definitions written against generated Gherkin tend to encode the generator's assumptions, not the system's actual behavior — a problem documented in detail when examining how AI-generated steps break scenario isolation. Use AI to draft scenario skeletons before the session, then stress-test them in the room.

A well-run Three Amigos workshop produces a feature file that a CI pipeline can execute on the first commit — no rework, no clarification emails. If you implement the structure here, the next metric worth tracking is scenario churn rate: how often a scenario is rewritten after the story is coded. High churn means ambiguity survived the session. Pair this with a look at how those scenarios fit into a broader scalable BDD framework to see the full pipeline from workshop to green build.

Note: This article is for informational purposes only and is not a substitute for professional advice. If you need guidance on specific situations described in this article, consider consulting a qualified professional.