Writing Better Acceptance Criteria with the Given–When–Then Framework

Introduction

You’ve gathered requirements, written user stories, and aligned with stakeholders. But how do you ensure your development team actually understands what’s expected?

That’s where Acceptance Criteria comes in — and when written using the Given–When–Then format, it becomes a simple, structured way to express behavior and expectations clearly.

Let’s dive into how to write better acceptance criteria using this framework — with templates, examples, and pitfalls to avoid.

---

What is the Given–When–Then Framework?

Given–When–Then is a format from Behavior-Driven Development (BDD) that helps describe the preconditions, action, and expected outcome of a system behavior.

---

Structure

• Given – the starting state or precondition

• When – the action a user (or system) performs

• Then – the expected result or output

Think of it like setting up a scenario:

“Given” this situation,
“When” something happens,
“Then” here’s what should result.

---

Example 1 – Login Functionality

User Story:
As a registered user, I want to log into my account so I can access my dashboard.

Acceptance Criteria:

Scenario 1: Successful login
Given the user is on the login page  
When they enter a valid email and password  
Then they should be redirected to the dashboard

Scenario 2: Invalid login
Given the user is on the login page  
When they enter an incorrect password  
Then an error message “Invalid credentials” should be displayed

---

Example 2 – Leave Request Workflow

User Story:
As an employee, I want to submit a leave request so my manager can review and approve it.

Acceptance Criteria:

Scenario 1: Submit leave request
Given the employee is logged into the HR portal  
When they select leave dates and click “Submit”  
Then the request status should be marked as “Pending Approval”

Scenario 2: Leave request conflict
Given the employee already has an approved leave on the selected date  
When they try to submit another request  
Then an error message “Leave already applied for selected dates” should be shown

---

Templates You Can Reuse

Scenario: [Brief Description]
Given [initial condition or system state]  
When [user/system performs an action]  
Then [expected result or behavior]

You can also add:

• And – to chain multiple conditions or results

• But – to handle exceptions

---

Common Mistakes to Avoid

---

When Should a BA Write Acceptance Criteria?

• While refining user stories

• During grooming/backlog sessions

• Before handing over requirements to developers

• After stakeholder feedback to clarify scope

• As part of test case preparation with QA

---

Why It Works

• Aligns everyone — business, developers, and testers

• Reduces assumptions and miscommunication

• Makes testing and validation easier

• Helps define “done” clearly and measurably

---

Final Thoughts

Writing solid acceptance criteria using Given–When–Then isn’t just a formatting trick — it’s a way to build shared understanding and reduce rework.

It forces you to slow down and ask:

“What exactly should happen — and in what situation?”

And when that clarity exists, great software follows.

---

What You Can Try Today:

Take one of your user stories and rewrite the acceptance criteria in Given–When–Then format. You’ll be surprised how much clearer it becomes — even to you.