How to Write Acceptance Criteria That Engineers Actually Follow

You've spent hours crafting what you think are clear requirements. You've outlined every detail that matters to users. Yet somehow, when the feature lands in QA, it's missing half the functionality you specified. Sound familiar?

"I've got a number of devs that literally just up and don't do the things I ask in the requirements," laments one frustrated product manager on Reddit. Meanwhile, engineers complain about "indecisive PMs that bring vague descriptions" and then "alter the acceptance criteria to add more requirements after the story had already been implemented."

This isn't a case of difficult engineers or micromanaging product managers. It's a communication breakdown—and poorly written acceptance criteria are often the culprit.

In this guide, you'll learn how to create acceptance criteria that serve as a clear contract between product and engineering teams—criteria that engineers will not just understand, but actually want to follow.

What Are Acceptance Criteria (And What They're Not)

Before diving into best practices, let's clarify what we're talking about:

Acceptance Criteria (AC) are the conditions that a product must satisfy to be accepted by a user, customer, or system. They're essentially a pass/fail checklist that defines when a specific user story is complete.

However, acceptance criteria are often confused with other product artifacts:

• User Stories vs. AC: A user story describes the why from a user's perspective ("As a user, I want to reset my password so I can regain access to my account"). Acceptance criteria define the what and specific conditions that must be met.
• Definition of Done (DoD) vs. AC: Your team's Definition of Done is a standard checklist applied to all work (code reviewed, tests written, documentation updated). Acceptance criteria are unique to each individual user story.

Why Most Acceptance Criteria Fail (Common Pitfalls)

When QA professionals watch colleagues "patting themselves on the back for delivering value at breakneck speeds" while the product is an "epic mess", something has gone terribly wrong with your acceptance criteria. Here's why this happens:

Mistake #1: They're Too Vague or Too Broad

Broad statements like "The user should be able to search for products" leave too much room for interpretation. Engineers are forced to make assumptions, leading to gaps between expectations and implementation.

Mistake #2: They're Too Prescriptive

The opposite problem occurs when product managers dictate exactly how to implement a feature. This strips engineers of their autonomy and expertise in finding the best technical solution.

Mistake #3: They're Written in Isolation

When a Product Owner writes AC alone (without developer or QA input), they miss crucial technical context and edge cases. This leads to incomplete criteria that don't account for real-world scenarios.

Mistake #4: They're a Moving Target

Nothing frustrates engineers more than a PM who changes requirements after development has begun. This "scope creep" destroys trust and planning.

One product manager reported that their "product was an epic mess until I started reigning that in with very defined acceptance criteria." Let's see how to write those well-defined criteria.

The Blueprint for Effective Acceptance Criteria

Principle 1: Make it a Team Sport

Effective AC emerge from collaboration, not isolation. While the Product Owner typically drafts initial criteria, the entire team should refine them together:

• Who writes them? The Product Owner drafts, but developers and QA must review, question, and refine them.
• When to write them? Define AC during backlog refinement or sprint planning—never during active development. As one PM notes, "Acceptance Criteria should be written on the story before it is started."

Principle 2: Choose the Right Format for the Job

Different types of features call for different formats:

Scenario-Oriented Format (Given/When/Then)

Best for user-facing interactions and the foundation of Behavior-Driven Development (BDD):

Given [the initial context]
When [an action occurs]
Then [this outcome should happen]

Example (Password Reset):

Given I am on the login page
When I click "Forgot Password" and enter a valid email
Then I should receive a confirmation message
And I should receive a password reset email within 1 minute

Rule-Oriented Format (Checklist)

Best for non-functional requirements or when a specific user flow isn't applicable:

Example (Search Functionality):

• The search field appears in the top navigation bar
• Search is not case-sensitive
• Search results display within 2 seconds
• Results are sorted by relevance by default
• Each result displays the product image, name, and price

Principle 3: Ensure They're Clear, Concise, and Testable

Each criterion must be a pass/fail statement with no ambiguity:

• Bad (Not Testable): The dashboard should load quickly.
• Good (Testable): The dashboard should load in under 3 seconds on a standard broadband connection.

If your QA team can't write a test case for a criterion, it's not well-defined.

Principle 4: Focus on Outcomes, Not Implementation

Describe what the user will experience, not how to build it. According to Scrum Alliance, effective AC should focus on the "what," not the "how."

• Bad (Implementation-focused): Use a PostgreSQL database to store user preferences.
• Good (Outcome-focused): User preferences should persist between sessions.

A Step-by-Step Guide to Writing AC (with Examples)

Let's walk through creating acceptance criteria for a real feature:

Step 1: Start with a Clear User Story

As a shopper, I want to filter products by price range so I can find items within my budget.

Step 2: Brainstorm Scenarios (Happy and Unhappy Paths)

Consider both ideal flows and edge cases:

• What happens when a user sets only a minimum price?
• What if no products match the filter?
• What if a user enters invalid values?

Step 3: Draft the AC Using the Chosen Format

For this feature, the scenario-oriented format works well:

Scenario 1: User filters products by price range

Given I am on the product listing page
When I set minimum price to $20 and maximum price to $50
And I click "Apply Filters"
Then only products with prices between $20-$50 should display
And the number of results should be visible

Scenario 2: No products match the filter criteria

Given I am on the product listing page
When I set a price range that no products match
And I click "Apply Filters"
Then I should see a message "No products match your criteria"
And I should see an option to "Clear filters"

Scenario 3: User enters invalid values

Given I am on the product listing page
When I enter a negative number in the minimum price field
Then I should see an error message "Please enter a valid price"
And the filter should not be applied

Step 4: Review and Refine with the Team

Present your draft AC during refinement and ask specific questions:

• "Is anything unclear?"
• "Are we missing any edge cases?"
• "Can we test all of these criteria?"

This collaborative discussion builds shared ownership and prevents misunderstandings. As noted by one developer, teams function best when "everyone has a sharp eye, a sense of how the business works, empathy for our users, and a high bar for quality."

Step 5: Get Consensus and Freeze the AC

Once the team agrees, the AC should be considered final for the upcoming sprint. This prevents the frustrating problem of "PM altering the AC to add more requirements after the story had already been implemented."

Tools and Workflow Integration

Your carefully crafted acceptance criteria need a home. Here's how to manage them in Jira:

• Description Field: Simple but can get messy with complex AC
• Custom Field: Create a dedicated "Acceptance Criteria" field
• Checklist Plugins: Use add-ons like "Checklist for Jira" to create interactive AC lists

Whatever tool you choose, make sure your AC are visible, easily accessible, and clearly formatted for the entire team.

Finding the Right Balance

One product manager described their challenge as "finding the right balance of 'how strict do acceptance criteria need to be?'" There's no one-size-fits-all answer, but consider this guideline: the more complex the feature and the less familiar the team is with the domain, the more detailed your AC should be.

Some teams find it helpful to categorize AC as "must-have" versus "nice-to-have" to help prioritize the essential requirements while allowing room for interpretation on less critical aspects.

Conclusion: From Friction to Flow

Acceptance criteria aren't just another box to check in your development process—they're the bridge that connects product vision to technical implementation.

When crafted collaboratively, written clearly, and finalized before development, AC transform from a source of friction to a powerful communication tool that aligns the entire team. They provide engineers with the clarity they need while preserving the autonomy they deserve.

Remember: the goal isn't to create perfect documentation. The goal is to build the right product, right. Well-written acceptance criteria are your best tool to make that happen.

By investing time upfront to create excellent AC, you'll prevent the frustration of incomplete features, reduce rework, stop scope creep, and ultimately ship better products that truly meet user needs. And that's something both product managers and engineers can get behind.

Frequently Asked Questions

What is the main difference between Acceptance Criteria and a User Story?

Acceptance Criteria define the specific pass/fail conditions a feature must meet, while a User Story describes the user's goal and motivation. Think of it this way: the User Story provides the "why" from a user's perspective (e.g., "As a user, I want to reset my password..."), while the AC provides the "what" that makes the story complete (e.g., "Given I enter a valid email, Then I receive a reset link.").

Who is responsible for writing Acceptance Criteria?

The Product Owner or Product Manager typically drafts the Acceptance Criteria, but the entire team—including developers and QA—is responsible for collaboratively refining and agreeing upon them. This team-based approach is crucial because developers can identify technical constraints and edge cases, while QA can ensure each criterion is testable.

When should Acceptance Criteria be written?

Acceptance Criteria should be written and finalized before a user story is scheduled for development. The best time for this is during backlog refinement or sprint planning meetings. Finalizing AC before the sprint starts prevents scope creep and ensures the engineering team has a clear, stable target to work towards.

How do you write good Acceptance Criteria?

Good Acceptance Criteria are written collaboratively, focus on outcomes rather than implementation, are clear and testable, and use a consistent format. The best AC are unambiguous pass/fail statements. Using formats like the scenario-oriented (Given/When/Then) approach for user interactions or a rule-oriented checklist for system requirements helps maintain clarity and ensures everyone understands what needs to be delivered.

Why are Acceptance Criteria important in Agile development?

Acceptance Criteria are important because they create a shared understanding of what "done" means for a specific feature, serving as a contract between the product and engineering teams. They prevent ambiguity and miscommunication, reduce rework, empower QA with clear test cases, and ultimately ensure that the final product aligns with both business requirements and user needs.

What is the difference between Acceptance Criteria and the Definition of Done (DoD)?

Acceptance Criteria are unique rules for an individual user story, while the Definition of Done (DoD) is a general checklist that applies to all work items. For example, an AC for a login feature might be "User sees an error on invalid password entry." The DoD, in contrast, would include team-wide standards like "Code is peer-reviewed," "Automated tests are passing," and "Documentation is updated," which are required for any story to be considered complete.