Given When Then Style

Who this is for

This lesson is for Business Analysts, Product Owners, QA, and Developers who want crisp, testable acceptance criteria that reduce miscommunication and rework.

Prerequisites

• Basic understanding of user stories (As a... I want... So that...)
• Knowledge of the product domain you are writing for
• Ability to identify inputs, rules, and expected outcomes

Why this matters

Given-When-Then (GWT) acceptance criteria make behaviors unambiguous and testable. In day-to-day BA work, you will:

• Clarify edge cases in grooming sessions
• Align product, engineering, and QA on what "done" means
• Reduce scope creep by describing exact outcomes
• Enable automated testing because scenarios are structured

Concept explained simply

GWT describes behavior like a mini-story with three parts:

• Given — the starting state or preconditions
• When — the action the user/system performs
• Then — the observable outcome

Add And to join multiple preconditions or outcomes. One scenario = one behavior.

Mental model

Think of GWT as a camera scene:

• Given sets the scene (what exists on screen)
• When captures the action (what the actor does)
• Then shows the visible result (what the audience can verify)

Scenario: Login with valid credentials
Given a registered user with email verified
And the user is on the login page
When the user enters a valid email and correct password
Then the user is signed in
And the dashboard is displayed

Format and rules you can rely on

1. Write in plain language; avoid UI implementation terms unless necessary.
2. One behavior per scenario; add more scenarios for different rules or edge cases.
3. Keep Then outcomes observable (visible state change, message, data saved).
4. Keep business rules explicit (e.g., minimum amounts, limits, time windows).
5. Cover happy path and critical negative paths (invalid inputs, permissions).

• Checklist to self-review:
  • Have I stated the preconditions?
  • Is the trigger action clear?
  • Is the outcome verifiable by a tester?
  • Are edge cases covered by additional scenarios?

Worked examples

Scenario: Request password reset with registered email
Given a registered user with email alice@example.com
And the user is on the "Forgot password" page
When the user submits alice@example.com
Then a reset email is sent to alice@example.com
And a confirmation message is shown

Scenario: Request password reset with unregistered email
Given no user exists with email bob@example.com
When the user submits bob@example.com
Then no email is sent
And a generic confirmation message is shown (no account existence is revealed)

Scenario: Apply 10% discount code to eligible cart
Given the cart total before discount is $100
And the code SAVE10 is valid and not expired
When the user applies code SAVE10
Then the discount of $10 is applied
And the new total is $90

Scenario: Decline expired discount code
Given the cart total before discount is $100
And the code SAVE10 expired yesterday
When the user applies code SAVE10
Then the code is rejected
And the user sees an "Expired code" message

Scenario: Analyst downloads monthly report
Given the user has role Analyst
And the March 2025 report is available
When the user requests the report
Then the report file is downloaded

Scenario: Viewer is denied report download
Given the user has role Viewer
When the user requests the report
Then access is denied
And the user sees "You don’t have permission"

How to write GWT in five steps

1. Identify the single behavior you want to prove done.
2. List preconditions (data, role, state, page). These become Given lines.
3. Describe the trigger action in one When line.
4. List visible outcomes (state change, messages, navigation, persisted data) as Then/And.
5. Duplicate the scenario to cover key alternate paths (invalid input, limits).

Scenario: <short behavior name>
Given <precondition 1>
And <precondition 2>
When <single action>
Then <first observable outcome>
And <second observable outcome>

Common mistakes and how to self-check

• Mixing multiple behaviors in one scenario
  Fix: Split into separate scenarios (e.g., success vs. failure).
• Unobservable outcomes (e.g., "data updated")
  Fix: Specify the exact visible change (e.g., "order status shows ‘Shipped’").
• Missing preconditions
  Fix: Add data, role, and state to Given.
• UI over-specification (e.g., "click the green round button")
  Fix: Describe the action generically unless the UI behavior is the requirement.
• Ambiguous numbers/rules (e.g., "large order")
  Fix: Use explicit thresholds (e.g., "orders over $500").

Exercises

Practice here, then submit your answers below in your editor or notes. Compare with the solution when ready.

• Checklist before you compare:
  • One action per scenario
  • Clear preconditions (data, role, page)
  • Then outcomes are specific and testable
  • Alternate paths covered

Practical projects

1. Backlog cleanup sprint
   • Pick 5 existing user stories
   • Add 2–4 GWT scenarios to each
   • Review with QA; refine until testable
2. Edge case catalog
   • List common failure modes (timeouts, invalid inputs, permissions)
   • Create a scenario for each mode in one feature area
3. Automation-ready pack
   • Choose one feature
   • Write GWT with stable data and IDs
   • Pair with QA/dev to turn 3 scenarios into automated tests

Learning path

• Master Given-When-Then for simple and alternate flows
• Add examples of business rules and edge cases
• Collaborate in 3 Amigos sessions (BA, Dev, QA)
• Connect scenarios to test cases and Definition of Done
• Scale: organize scenarios by feature and tags

Next steps

• Use the template in your next grooming session
• Convert two vague stories into GWT before sprint planning
• Share with QA for quick validation

Mini challenge

Write two scenarios for search suggestions: one with at least 3 suggestions, one with none. Include preloaded data and user role.

Quick Test

Note: The test is available to everyone; only logged-in users get saved progress.