Acceptance Criteria Examples and Template: Copy, Paste, Ship

What Is Acceptance Criteria and Why It Matters

Imagine you write a user story, the team builds it, and during sprint review the product owner says, "This isn't what I meant." Three days of work, gone. The culprit? Missing or vague acceptance criteria.

Acceptance criteria are the specific, testable conditions a user story must satisfy before it can be considered complete and accepted by stakeholders.

What Acceptance Criteria Actually Means

So what is acceptance criteria in practice? It's the set of pass/fail statements that define the boundaries of a user story. If the story is the intent ("I want to reset my password"), the acceptance criteria are the boundaries ("Reset link expires after 30 minutes," "User receives email within 2 minutes," "Invalid tokens display an error message").

This is different from general requirements or project-level specifications. The definition of acceptance criteria is story-specific: each criterion describes a single verifiable behavior that the product owner, developer, and QA engineer all agree on before work begins. Think of it as a contract between those three roles, written in plain language that everyone can understand and test against.

Why Every User Story Needs Acceptance Criteria

Without clear criteria, teams face predictable problems. Scope creep sneaks in because nobody defined what's "in" and what's "out." Sprints fail because developers built to their own assumptions. QA can't write test cases until the code is already done, which delays feedback loops.

Well-written acceptance criteria eliminate ambiguity upfront. They give developers defined edges for estimation, give testers a head start on validation, and give product owners confidence that what ships matches what was envisioned. Teams that invest twenty minutes defining acceptance criteria during refinement can reduce development cycles by 25-30% by cutting rework and misalignment.

The definition of acceptance criteria may sound simple, but getting it right is what separates teams that ship predictably from teams that constantly renegotiate scope mid-sprint. The real question becomes: what format should you use to write them?

Acceptance Criteria Formats and When to Use Each

Three acceptance criteria formats dominate agile teams, yet picking the right one for a given story is where most teams stumble. Each format solves a different communication problem. Here's how to choose.

Given-When-Then Scenario Format

The Given/When/Then format, also called Gherkin acceptance criteria, structures each criterion as a scenario with three parts: a precondition, an action, and an expected outcome. It looks like this:

• Given the user is on the login page

• When they enter an invalid password three times

• Then the account is temporarily locked for 15 minutes

This format shines when you need precision. Because each scenario isolates a single behavior, QA can translate given when then acceptance criteria directly into automated test scripts using tools like Cucumber or SpecFlow. Teams practicing behavior-driven development (BDD) rely on it heavily, and you'll find most given when then acceptance criteria examples follow this exact pattern across documentation and test suites alike.

Checklist Format for Straightforward Features

When a story is simple and the team just needs a pass/fail list, a checklist works best. No ceremony, no syntax, just bullet points describing what "done" looks like:

• Export includes all active users

• File format is CSV, UTF-8 encoded

• Download completes in under 5 seconds for up to 10,000 records

• Columns include name, email, signup date, and last login

Checklists are ideal for teams new to acceptance criteria or for features where the logic is linear and doesn't branch into multiple scenarios. They're fast to write, easy for non-technical stakeholders to review, and reduce overhead during refinement sessions.

Rule-Based Format for Complex Logic

Some features involve conditional business logic that doesn't map cleanly to a single scenario or a flat checklist. The rule-based acceptance criteria format uses "If X, then Y" statements to capture branching behavior:

• If payment fails, then send an alert to the billing team

• If three consecutive failures occur, then lock the account and notify the user

• If payment succeeds after retry, then remove the lock and send confirmation

This format works well for integrations, pricing engines, and workflow automations where multiple conditions drive different outcomes. It keeps the logic readable without forcing every branch into a full Given/When/Then scenario.

Choosing the Right Format

The most commonly used acceptance criteria formats in agile organizations are scenario-oriented and checklist-based, but the best choice depends on your context. Here's a side-by-side comparison:

A practical rule of thumb: if the story has more than two branching paths, reach for Given/When/Then or rule-based. If it's a single happy path with clear boundaries, a checklist keeps things moving. Many teams mix formats within the same backlog depending on story complexity, and that's perfectly fine.

Knowing the format is half the equation. The other half is seeing how these formats look when applied to real user stories across different project types.

Real Acceptance Criteria Examples for User Stories

Formats make sense in theory, but you really internalize them when you see acceptance criteria examples applied to actual user stories. The following examples span common project types you'll encounter in modern product development, from authentication flows to API integrations and commerce platforms. Each one pairs a user story with testable criteria written in the appropriate format.

Use these as sample acceptance criteria for user stories on your own backlog. Adapt the structure, swap in your domain language, and you'll have production-ready criteria in minutes.

Login Page Acceptance Criteria Example

Authentication is the classic starting point, and for good reason: every product has a login page, and the acceptance criteria for login page features demonstrate Given/When/Then structure clearly.

User Story: As a registered user, I want to log in with my email and password so that I can access my account securely.

1. Given the user is on the login page When they enter a valid email and correct password and click "Log In" Then the system redirects them to the dashboard within 2 seconds.

2. Given the user enters an incorrect password When they click "Log In" Then the system displays the message "Invalid email or password" without revealing which field is wrong.

3. Given the user fails authentication five consecutive times When they attempt a sixth login Then the account is locked for 30 minutes and a notification email is sent to the registered address.

4. Given the user checks "Remember me" and logs in successfully When they close the browser and return within 7 days Then the session persists and no re-authentication is required.

Notice how each criterion isolates one behavior and includes a measurable outcome. There's no ambiguity about what "secure login" means because the boundaries are explicit.

API Endpoint and Data Pipeline Examples

Developers encounter API and data stories daily, yet most acceptance criteria for user stories examples skip these entirely. Here's how to write testable criteria for technical features.

User Story: As a mobile client developer, I want a REST endpoint that returns a user's order history so that I can display past purchases in the app.

1. The endpoint GET /api/v1/users/{id}/orders returns a 200 response with a JSON array of orders sorted by date descending.

2. Each order object includes order_id, status, total_amount, currency, and created_at fields.

3. If the user has no orders, the endpoint returns a 200 with an empty array, not a 404.

4. Requests without a valid authentication token receive a 401 response with an error message body.

User Story: As a data analyst, I want the nightly ETL pipeline to sync customer records from the CRM into the data warehouse so that dashboards reflect up-to-date information.

1. The pipeline runs daily at 02:00 UTC and completes within 45 minutes for up to 500,000 records.

2. New and updated CRM records are upserted; deleted records are soft-deleted with a timestamp.

3. If the pipeline fails, an alert is sent to the #data-ops Slack channel within 5 minutes, including the error message and affected batch ID.

These criteria examples use the checklist format because the logic is linear and the audience is technical. No Given/When/Then ceremony needed.

E-Commerce and SaaS Feature Examples

Industry-specific stories often carry compliance or business-rule weight. Here are user stories examples with acceptance criteria that reflect those realities.

User Story: As a shopper, I want to apply a discount code at checkout so that I can receive promotional pricing on eligible items.

1. When a valid code is entered, the discount is applied and the order total updates instantly without a page reload.

2. If the code is expired or invalid, the system displays "This code is not valid" and does not alter the total.

3. Only one discount code can be applied per order; entering a second code replaces the first.

4. Discount applies only to eligible items as defined by the promotion rules; ineligible items display their original price.

User Story: As a SaaS account admin, I want to invite team members during onboarding so that my team can collaborate from day one.

1. The "Invite Team" step appears in the onboarding flow after account creation.

2. Each invite sends an email containing a unique, single-use link that expires after 72 hours.

3. Invited members appear as "Pending" in the team roster until they accept.

4. The admin can complete onboarding without inviting anyone; the step is skippable.

These sample acceptance criteria for user stories balance business intent with testability. The e-commerce example accounts for edge cases like expired codes, while the SaaS example ensures the flow doesn't block users who aren't ready to invite teammates yet.

Functional features like these get the most attention during refinement, but some of the highest-risk gaps hide in what teams don't write criteria for: performance thresholds, security hardening, and accessibility compliance.

Acceptance Criteria for Non-Functional Requirements

Most backlogs are packed with functional stories: login flows, checkout pages, API endpoints. But when a production system buckles under load or fails a security audit, the root cause is almost always the same. Nobody wrote testable acceptance criteria for the non-functional stuff.

Non-functional requirements, sometimes called quality attributes or system constraints, describe how the system behaves rather than what it does. Think response times, uptime guarantees, encryption standards, and accessibility compliance. These attributes are universally needed yet routinely overlooked during refinement because they don't map neatly to a single user-facing feature.

The distinction between acceptance criteria vs requirements matters here. Traditional requirements documents might state "the system shall be fast." Acceptance criteria for user stories demand specifics: how fast, under what load, measured where, and what happens when the threshold is breached. That precision is what makes non-functional AC testable and enforceable.

As Mike Cohn of Mountain Goat Software frames it, non-functional requirements are best understood as constraints on the system. Each constraint narrows the design choices, and expressing them as user stories with clear acceptance criteria keeps them visible on the backlog rather than buried in a forgotten wiki page.

Performance and Scalability Criteria

Performance criteria need numbers. Without measurable thresholds, "the page should load quickly" becomes a subjective debate during sprint review. Here's an example of acceptance criteria written for a performance-sensitive feature:

User Story: As a user, I want the dashboard to load within an acceptable time frame so that I can start my work without waiting.

• The dashboard renders fully within 2 seconds on a 4G connection with up to 50 widgets configured.

• Under peak load of 10,000 concurrent users, server response time for the dashboard API does not exceed 500ms at the 95th percentile.

• If response time exceeds 3 seconds, a loading skeleton is displayed and the system logs a performance warning to the monitoring service.

• The system supports horizontal scaling to handle a 200% traffic spike during business hours without manual intervention.

Scalability criteria follow the same principle. They define the growth ceiling and what happens when the system approaches it:

• The database query layer handles up to 1 million records per table without query times exceeding 200ms.

• Adding a new application node to the cluster requires zero downtime and completes within 5 minutes.

• The message queue processes up to 50,000 events per minute without message loss or duplicate delivery.

Notice the pattern: each criterion includes a specific metric, a boundary condition, and an observable outcome. This is what separates agile methodology acceptance criteria from vague performance wishes. QA can build load tests directly from these statements, and the team knows exactly when the story passes or fails.

Security and Accessibility Criteria

Security and accessibility are two areas where missing acceptance criteria create real liability, not just technical debt. A security gap can lead to a breach; an accessibility gap can exclude users and violate legal requirements.

Security acceptance criteria examples:

• All API endpoints require a valid JWT token; requests without a token return a 401 response within 100ms.

• User passwords are hashed using bcrypt with a minimum cost factor of 12; plaintext passwords are never stored or logged.

• Session tokens expire after 30 minutes of inactivity and cannot be reused after expiration.

• All data in transit uses TLS 1.2 or higher; connections attempting older protocols are rejected.

• Failed login attempts are rate-limited to 5 per minute per IP address; exceeding the limit triggers a 429 response and a security event log entry.

Accessibility acceptance criteria examples:

• All interactive elements are reachable and operable via keyboard alone, with a visible focus indicator meeting WCAG 2.1 AA contrast requirements.

• Images include descriptive alt text; decorative images use an empty alt attribute.

• Form fields have programmatically associated labels; error messages identify the field in error and suggest a correction.

• Color is not used as the sole means of conveying information; status indicators include text or icon alternatives.

• The page passes automated checks using axe-core with zero critical or serious violations.

These criteria are concrete enough for a developer to implement against and for QA to verify with specific tools. Security criteria map to penetration test scenarios. Accessibility criteria map to both automated scans and manual screen reader testing.

Integrating Non-Functional AC Without Overwhelming the Backlog

Teams skip non-functional criteria for a practical reason: writing them for every story feels like overhead. The solution isn't to attach performance and security criteria to every single ticket. Instead, treat cross-cutting non-functional concerns in two ways:

• Dedicated constraint stories: Create standalone user stories for system-wide requirements like "As the operations team, I want the platform to maintain 99.9% uptime so that customers aren't impacted by outages." These live on the backlog, get estimated, and get tested like any other story.

• Embedded criteria on high-risk stories: For features that touch sensitive areas (payment processing, user data, public-facing pages), add non-functional criteria directly to the story's acceptance criteria alongside the functional ones.

Research into managing non-functional requirements in agile shows that companies successfully handling these constraints either convert them into dedicated user stories or embed them into the team's Definition of Done. Both approaches keep non-functional quality visible without burying every story under a wall of criteria.

The key insight: non-functional acceptance criteria aren't optional extras. They're the difference between software that works in a demo and software that survives production. Teams that treat them with the same rigor as functional criteria catch problems in sprint review instead of in incident postmortems.

Writing good criteria, whether functional or non-functional, is a skill. And like any skill, it's easier to sharpen when you can see what bad looks like next to what good looks like.

Bad vs Good Acceptance Criteria Anti-Patterns

You can study formats and templates all day, but nothing sharpens your instincts faster than seeing a weak criteria example next to its corrected version. The patterns below come from real backlogs, and every one of them has caused a sprint to derail at least once.

Vague and Untestable Criteria Rewritten

The table below shows four common anti-patterns alongside their corrected versions. Each bad example of criteria fails for a specific, identifiable reason. Each corrected version is something a developer can build against and QA can verify without guesswork.

Why the originals fail:

• Row 1 - Ambiguous language: "Fast" and "responsive" mean different things to different people. Without a number, there's no way to write a test or agree on pass/fail.

• Row 2 - Implementation-prescriptive: Specifying Redis dictates the how instead of the what. The corrected version defines the outcome and lets the engineering team choose the right tool.

• Row 3 - Compound criteria: Bundling profile updates and email notifications into one statement makes it impossible to test independently. If the save works but the email doesn't, did the criterion pass or fail?

• Row 4 - Missing boundaries: "Work properly" is untestable. The corrected version specifies the trigger, the retry logic, the user-facing message, and the safety constraint (no duplicate charge).

These examples of acceptance criteria gone wrong share a common thread: they leave room for interpretation. And interpretation is where misalignment lives.

Common Mistakes Teams Make with Acceptance Criteria

Beyond wording issues, teams fall into process-level traps that undermine even well-formatted criteria:

• Writing AC after development starts. When criteria are drafted mid-sprint, they describe what was built rather than what should be built. This defeats the purpose entirely. A common observation from agile practitioners is that late-written criteria lead to mismatched expectations and invisible rework. Criteria should be finalized before sprint planning so everyone shares the same definition of done from day one.

• Confusing acceptance criteria with tasks. "Set up the database schema" or "Write unit tests" are implementation tasks, not acceptance criteria. Criteria describe observable outcomes from the user's or system's perspective, not the steps a developer takes to get there.

• Gold-plating with excessive criteria. If a single story has 15 acceptance criteria, the story is probably too large. Overloaded criteria signal that the story needs splitting. Aim for 3-7 criteria per story to keep scope manageable and testable.

• Assuming the obvious. What feels self-evident to one team member may be invisible to another. A sample of acceptance criteria that seems "too basic" to write down, like "the form is accessible via keyboard," is exactly the kind of criterion that prevents bugs from reaching production. Spell it out.

These mistakes compound silently. One vague criterion leads to one assumption, which leads to one rework cycle, which delays the sprint by days. The fix is straightforward: treat every examples of criteria you write as something a stranger should be able to verify without asking a single clarifying question.

Recognizing anti-patterns is the diagnostic step. The next step is having a reusable structure you can reach for every time you sit down to write criteria from scratch.

Copy-Paste Acceptance Criteria Template

Having a reusable acceptance criteria template eliminates the blank-page problem during refinement. Instead of reinventing structure every sprint, you grab the template, fill in the specifics, and focus your energy on the edge cases that actually require thought. As Chris Hamm at BizStream puts it, templates reduce decision fatigue so your brain budget goes toward solving complex problems rather than remembering what sections to include.

Below is a user story acceptance criteria template you can copy directly into your project management tool and adapt to any feature.

User Story with Acceptance Criteria Template

User Story: As a [role], I want to [action] so that [benefit]. Acceptance Criteria (Given/When/Then): Scenario 1: [Happy path description] - Given [precondition], When [action], Then [expected outcome]. Scenario 2: [Error/edge case description] - Given [precondition], When [action], Then [expected outcome]. Acceptance Criteria (Checklist): The feature [does X]. The system [handles Y within Z threshold]. Invalid input displays [specific error message]. [Accessibility/security constraint met]. Edge Cases and Boundaries: What happens when [empty state]? What happens when [maximum limit reached]? What happens when [concurrent access]? Assumptions: [List conditions the team is basing decisions on.] Out of Scope: [Explicitly state what this story does NOT cover.]

This user story template with acceptance criteria covers the full spectrum: structured scenarios for complex paths, a checklist for straightforward validations, explicit edge cases, and scope boundaries. The assumptions and out-of-scope sections prevent the mid-sprint "I thought we were also doing..." conversations that derail velocity.

You'll notice the template supports both formats simultaneously. That's intentional. Some criteria within a single story benefit from Given/When/Then precision while others are simple enough for a checklist line. Use whichever format communicates each criterion most clearly.

A user story and acceptance criteria template like this works in Jira, Linear, Azure DevOps, or any tool that supports text fields on tickets. The structure stays the same regardless of where you paste it.

Organizing Templates and PRD Context in One Workspace

Templates solve the structure problem, but teams still struggle with a fragmentation problem. Your acceptance criteria user story template lives in one tool, the PRD lives in another, design links sit in a third, and the edge-case discussions from refinement are buried in Slack threads. When context is scattered, criteria drift out of sync with the broader product intent.

The practical fix is maintaining your user stories and acceptance criteria template alongside the PRD, design references, and refinement notes in a single workspace. AFFiNE's Pagedoc is built for exactly this workflow. It gives product and engineering teams a structured documentation space where acceptance criteria, Given/When/Then scenarios, checklists, and related PRD context live together in one organized place. Instead of copying templates into isolated tickets and losing the surrounding rationale, teams can keep living templates connected to the product decisions that shaped them.

Pagedoc supports the kind of structured documentation that keeps product managers and developers aligned: you can maintain your user story template acceptance criteria alongside feature specs, reference good and bad examples during refinement, and update everything in real time as requirements evolve. It's a single source of truth rather than a scavenger hunt across five tools.

A solid template gets you writing faster. But the real payoff comes when those criteria connect directly to what happens after the story is built: verification. The bridge between written criteria and passing tests is where acceptance criteria prove their value in production.

From Acceptance Criteria to Automated Test Cases

Well-written acceptance criteria don't just guide development. They become the test code. When your criteria follow a structured format like Given/When/Then, the path from written requirement to executable test is almost mechanical. This is the core idea behind behavior-driven development (BDD): acceptance criteria are the test specifications, expressed in a language both product owners and machines can parse.

Mapping Given-When-Then to Automated Tests

So what are acceptance tests in a BDD context? They're automated checks that validate system behavior against the exact scenarios your team agreed on during refinement. Tools like Cucumber (for Java, Ruby, JavaScript) and SpecFlow (for .NET) read Gherkin feature files and execute them as real tests against your application.

Here's an acceptance testing example showing how a criterion translates directly into executable code. Imagine this criterion from a password reset story:

• Given the user is on the "Forgot Password" page

• When the user submits a valid email "user@example.com"

• Then the system sends a password reset link to "user@example.com"

In Cucumber, that scenario lives in a .feature file written in plain Gherkin. Each line maps to a step definition, a small function that performs the actual action and asserts the expected outcome. The step definition for the Then line might assert that a reset email was queued for the correct address. The structure is one-to-one: one Given/When/Then line equals one step definition function.

This direct mapping is what makes acceptance test criteria examples so powerful. The same document that product owners review during refinement is the same artifact that runs in your test suite. No translation layer, no lost-in-handoff ambiguity.

Acceptance Criteria in CI/CD Pipelines

Structured criteria unlock continuous verification. When your acceptance tests are executable, they slot into your CI/CD pipeline alongside unit and integration tests. Here's the step-by-step flow from written criterion to passing build:

1. Product owner and team write acceptance criteria in Given/When/Then format during refinement.

2. A developer or QA engineer creates a .feature file containing those scenarios verbatim.

3. Step definitions are implemented in the project's language, wiring each Gherkin line to application code.

4. The CI pipeline runs behave, cucumber, or the equivalent test runner on every commit or pull request.

5. If any scenario fails, the build breaks and the team gets immediate feedback identifying which acceptance criterion isn't met.

This loop means acceptance testing with example scenarios happens continuously, not just at the end of a sprint. Every push validates that the software still satisfies the agreed-upon behaviors.

One important distinction: UAT acceptance criteria examples differ from developer-level unit tests in both scope and audience. Unit tests verify individual functions or methods in isolation. They're written by developers, run in milliseconds, and test internal correctness. Acceptance tests verify end-to-end behavior from the user's perspective. They confirm that the system does what stakeholders asked for, not just that individual code units work independently.

Both are essential. Unit tests catch implementation bugs fast. Acceptance tests catch requirement mismatches before they reach users. Teams that run both in their pipeline get rapid developer feedback and stakeholder-level confidence in every build.

Acceptance criteria that pass automated verification prove a story is functionally complete. But "complete" at the story level isn't the same as "shippable" at the increment level. That distinction is where Definition of Done enters the picture.

Definition of Done vs Acceptance Criteria Explained

A story passes all its acceptance criteria, yet the product owner still won't call it shippable. Confusing? It shouldn't be. The gap between "functionally correct" and "ready to release" is exactly where the Definition of Done lives. Teams that blur this boundary end up with stories that technically work but aren't reviewed, tested at the integration level, or documented. Understanding the definition of done vs acceptance criteria distinction prevents that disconnect.

Where Acceptance Criteria End and Definition of Done Begins

Acceptance criteria are story-specific. They describe what this particular feature must do to satisfy stakeholders. The Definition of Done (DoD) is team-wide. It describes the quality bar that every piece of work must clear before it counts as a releasable increment, regardless of which story it belongs to.

As Scrum.org explains, the DoD is a comprehensive checklist ensuring quality across functionality, performance, security, and compliance, applied to every Product Backlog Item. Acceptance criteria, on the other hand, are tailored to individual items and detail the expected behavior of that specific feature.

Here's a concrete example. Imagine a "Save for Later" feature on an e-commerce app:

Acceptance Criteria (story-specific):

• Users can click "Save for Later" on any product page.

• Saved items appear in a dedicated section of the user's account.

• Items can be moved back to the shopping cart with one click.

Definition of Done (applies to all stories):

• Code reviewed and merged into the main branch.

• Unit and integration tests pass with 80% coverage on new code.

• Feature deployed to the staging environment.

• Documentation and release notes updated.

The acceptance criteria confirm what the feature does. The DoD confirms it's ready to ship. A story isn't truly done until both boxes are checked.

How Both Work Together in Sprint Review

During sprint review, the product owner verifies each story against its acceptance criteria. Does the "Save for Later" button work? Do saved items appear in the right place? That's the AC check. Separately, the team confirms the DoD was met: code was reviewed, tests passed, staging deployment succeeded. If the AC passes but the DoD doesn't, the story isn't part of the increment. If the DoD passes but an acceptance criterion fails, the feature doesn't meet stakeholder expectations.

Both layers are essential. User stories and acceptance criteria ensure you built the right thing. The Definition of Done ensures you built it the right way.

Think of acceptance criteria vs definition of done as two complementary filters. The first filter catches functional gaps. The second catches quality and process gaps. Together, they give teams confidence that "done" genuinely means done, not "works on my machine."

Both concepts assume someone owns the criteria and someone refines them. But who actually writes acceptance criteria, and when do they get sharpened into something the whole team trusts? That's a collaboration question, and it deserves its own answer.

How Teams Collaborate on Acceptance Criteria

Acceptance criteria aren't a solo act. A product owner drafting criteria in isolation produces the same misalignment problems that missing criteria cause in the first place. The best teams treat writing and refining AC as a collaborative process where each role contributes a distinct perspective.

Who Writes Acceptance Criteria and When

The short answer: the product owner drafts them, but the whole team sharpens them. This collaborative model is often called the Three Amigos approach, where the product owner, a developer, and a tester each bring a different lens to the same user story and acceptance criteria.

Here's how the responsibilities typically break down:

• Product owner writes the initial draft based on customer needs and business intent. They define the "what" and the "why" behind each criterion.

• Developer adds technical edge cases the product owner may not anticipate: race conditions, null states, API timeout behaviors, and integration boundaries.

• QA engineer reviews for testability, ensuring every criterion is binary (pass or fail), unambiguous, and independently verifiable.

Timing matters as much as ownership. The product owner should draft initial criteria before backlog refinement, giving the team something concrete to react to rather than starting from scratch in the meeting. By the time sprint planning arrives, every example user story and acceptance criteria pair should be finalized and agreed upon.

If your team uses Jira, you'll notice that jira acceptance criteria fields work best when populated during refinement rather than mid-sprint. Writing criteria after development starts means you're documenting what was built, not what should be built, which defeats the purpose entirely.

Refining Criteria During Backlog Grooming

Backlog refinement is where acceptance criteria evolve from rough drafts into team-endorsed contracts. During these sessions, the product owner presents a sample user story and acceptance criteria, and the team pressure-tests them with questions like:

• "What happens if the user does X instead of Y?"

• "Is this criterion testable without manual intervention?"

• "Are we mixing two behaviors into one statement?"

Disagreements are natural and productive. A developer might argue that a performance threshold is unrealistic given the current architecture. A tester might flag that a criterion bundles two outcomes that need separate verification. The product owner resolves priority conflicts by anchoring decisions in user value. These conversations are how to write user story acceptance criteria that the entire team trusts, not just tolerates.

Teams that dedicate roughly 10% of sprint capacity to refinement consistently produce clearer criteria and shorter sprint planning sessions. The investment pays for itself in reduced rework and fewer mid-sprint surprises.

How to write acceptance criteria well isn't just about format or wording. It's about creating a shared space where product, engineering, and QA can see the same context, challenge each other's assumptions, and converge on a definition of done for each story. A shared documentation workspace like AFFiNE's Pagedoc makes this practical by giving all three roles a single place to collaboratively draft and refine acceptance criteria in real time. Scenarios, checklists, PRD context, and refinement notes stay visible to everyone involved rather than fragmenting across Slack threads, ticket descriptions, and meeting recordings. If your team is looking for a concrete next step to improve your AC workflow, centralizing that collaboration in one organized workspace is the highest-leverage change you can make.

Frequently Asked Questions About Acceptance Criteria

1. What is the difference between acceptance criteria and Definition of Done?

Acceptance criteria are story-specific conditions that define what a particular feature must do to satisfy stakeholders. The Definition of Done is a team-wide quality checklist applied to every backlog item, covering process standards like code review, test coverage, and staging deployment. A story needs to pass both its unique acceptance criteria and the universal Definition of Done before it can be considered shippable. Think of acceptance criteria as the functional filter and Definition of Done as the quality and process filter.

2. Who is responsible for writing acceptance criteria in agile teams?

The product owner typically drafts the initial acceptance criteria based on customer needs and business intent. However, the best results come from a collaborative approach called the Three Amigos, where a developer adds technical edge cases like timeout behaviors and null states, and a QA engineer reviews each criterion for testability. This ensures criteria are business-aligned, technically feasible, and independently verifiable. Teams can streamline this collaboration using a shared workspace like AFFiNE's Pagedoc, where all three roles can draft and refine criteria together in real time.

3. What is the Given/When/Then format for acceptance criteria?

Given/When/Then is a structured acceptance criteria format derived from Gherkin syntax used in behavior-driven development. 'Given' sets the precondition or context, 'When' describes the user action or trigger, and 'Then' states the expected outcome. For example: Given the user is on the login page, When they enter an invalid password three times, Then the account is locked for 15 minutes. This format maps directly to automated test tools like Cucumber and SpecFlow, making it ideal for teams that want executable specifications.

4. How many acceptance criteria should a user story have?

A well-scoped user story typically has 3 to 7 acceptance criteria. Fewer than 3 may indicate the story lacks defined boundaries or edge cases. More than 7 often signals the story is too large and should be split into smaller, independently deliverable pieces. Each criterion should test a single behavior and be independently verifiable. If you find yourself writing 10 or more criteria, consider whether you are bundling multiple features into one story or mixing acceptance criteria with implementation tasks.

5. Can acceptance criteria be used for non-functional requirements like performance and security?

Yes, and they should be. Non-functional acceptance criteria define measurable thresholds for system qualities like response time, uptime, encryption standards, and accessibility compliance. The key is specificity: instead of writing 'the system should be fast,' write 'the dashboard loads within 2 seconds on a 4G connection with up to 50 widgets configured.' Teams can either create dedicated constraint stories for system-wide requirements or embed non-functional criteria directly into high-risk feature stories that touch sensitive areas like payment processing or user data.

Related Blog Posts

1. 10 Best Faq Templates & Knowledge Base Tools For Customer ...

2. 19 Acceptance Criteria Examples for Different Products, Formats ...

3. What are Acceptance Criteria? Examples, Types & Templates