How many acceptance criteria should a single user story have?

Most stories need 3 to 8 criteria. Fewer than 3 usually means the story is underspecified. More than 8 suggests the story is too large and should be split into smaller stories. Use the criterion count as a signal for story sizing.

What is the difference between acceptance criteria and the definition of done?

Acceptance criteria are story-specific. They describe the behavior and outcomes for one particular feature or change. The definition of done is team-wide. It lists the quality gates every story must pass before it can be marked complete, such as code review, test coverage, and documentation updates.

Should acceptance criteria be written by the product manager or the development team?

The product manager typically writes the first draft of behavioral criteria because they define the expected user experience. Developers and QA then review and add technical scenarios, edge cases, and non-functional requirements. The final criteria are a shared agreement, not a one-way handoff.

Can I use acceptance criteria without the Given-When-Then format?

Yes. GWT is the most common format because it maps directly to automated test cases, but bullet-point checklists and plain-language descriptions also work. The key requirement is that each criterion is specific enough that two people would independently agree on whether it passes or fails.

How do acceptance criteria relate to automated testing?

Each Given-When-Then criterion translates directly into one or more automated test cases. The "Given" becomes the test setup, the "When" becomes the action, and the "Then" becomes the assertion. Teams that write criteria in GWT format find it faster to write end-to-end and integration tests because the test structure is already defined.

Acceptance Criteria Template

What This Template Is For

Acceptance criteria define what "done" looks like for a user story. Without clear criteria, developers build to assumptions, QA tests the wrong scenarios, and stakeholders reject finished work because it does not match what they expected. This template gives your team a repeatable format for writing criteria that are specific, testable, and complete.

The template uses the Given-When-Then (GWT) format for behavioral criteria and a supplementary checklist for non-functional requirements like performance, accessibility, and edge cases. If you are new to writing stories, start with the sprint planning template to see how criteria fit into the broader planning process. For teams using Kanban instead of Scrum, the Kanban board template shows how to attach criteria to cards in a flow-based system.

Well-written acceptance criteria reduce rework, speed up code review, and make sprint demos straightforward. The product-ops guide covers how to embed quality standards like these into your team's workflow. For a deeper look at how acceptance criteria connect to estimation, see the story points glossary entry.

When to Use This Template

During backlog refinement. Write criteria before stories enter a sprint so developers can ask clarifying questions early.
When a story has been rejected in review. Tighten the criteria to prevent the same misunderstanding from recurring.
For stories with multiple user types. Spell out different behavior paths for each persona.
When handing off between teams. Criteria serve as a contract between the requesting team and the building team.
Before a sprint planning session. Ensure every candidate story has at least three criteria before the team commits.
When onboarding new engineers. Use the template as a reference for how your team documents expected behavior.

How to Use This Template

Step 1: Start with the User Story

Write or paste the user story in the standard format: "As a [role], I want [action], so that [outcome]." This anchors every criterion to a real user need.

Step 2: Write Behavioral Criteria in GWT Format

For each distinct behavior the story introduces, write a Given-When-Then statement. Each statement should describe one scenario. Avoid combining multiple behaviors into a single criterion.

Step 3: Add Non-Functional Criteria

Check the supplementary checklist for performance, security, accessibility, and error-handling requirements that apply to this story.

Step 4: Review with the Team

Walk through the criteria with at least one developer and one QA engineer. Remove anything ambiguous. Add any scenarios the team identifies as missing.

Step 5: Attach to the Story and Estimate

Link the finalized criteria to the story in your project management tool. Use the criteria count and complexity to inform your story point estimate.

The Template

Story Details

Field	Value
Story ID	[e.g., PROJ-1234]
Story Title	[Short descriptive title]
User Story	As a [role], I want [action], so that [outcome]
Epic	[Parent epic name]
Priority	[Critical / High / Medium / Low]
Estimated Points	[e.g., 5]

Behavioral Acceptance Criteria (Given-When-Then)

Criterion 1: [Scenario Name]

Given [precondition or initial state]
When [action the user takes]
Then [expected result or system response]

Criterion 2: [Scenario Name]

Given [precondition or initial state]
When [action the user takes]
Then [expected result or system response]

Criterion 3: [Scenario Name]

Given [precondition or initial state]
When [action the user takes]
Then [expected result or system response]

Criterion 4: [Edge Case / Error Path]

Given [precondition or initial state]
When [unexpected or invalid action]
Then [error handling or fallback behavior]

Non-Functional Criteria Checklist

☐ Performance. Page loads in under 2 seconds on 3G connection
☐ Accessibility. All interactive elements have ARIA labels and keyboard navigation
☐ Security. User input is sanitized and validated server-side
☐ Responsiveness. Layout works on viewports from 320px to 1440px
☐ Error handling. Meaningful error messages display for all failure states
☐ Analytics. Key interactions fire the correct tracking events
☐ Localization. All user-facing strings are externalized for translation
☐ Browser support. Tested in Chrome, Firefox, Safari, and Edge

Definition of Done

☐ All behavioral criteria pass QA testing
☐ All non-functional criteria verified
☐ Code reviewed and approved by at least one peer
☐ Unit tests cover new logic (minimum 80% branch coverage)
☐ Documentation updated if API or UI changed
☐ Demo-ready for sprint review

Story Details

Field	Value
Story ID	AUTH-2847
Story Title	Add SMS-based two-factor authentication to login
User Story	As a registered user, I want to verify my identity with a one-time code sent to my phone, so that my account is protected even if my password is compromised
Epic	Account Security Hardening
Priority	Critical
Estimated Points	8

Behavioral Acceptance Criteria (Given-When-Then)

Criterion 1: Successful 2FA verification

Given the user has entered a valid email and password and has 2FA enabled
When they enter the correct 6-digit code sent to their registered phone number
Then they are logged in and redirected to the dashboard

Criterion 2: Incorrect code entry

Given the user is on the 2FA verification screen
When they enter an incorrect code
Then the system displays "Invalid code. Please try again." and the code field is cleared

Criterion 3: Code expiration

Given the user received a verification code more than 5 minutes ago
When they enter the expired code
Then the system displays "Code expired. Request a new code." with a resend button

Criterion 4: Maximum retry limit

Given the user has entered an incorrect code 5 times
When they attempt a 6th entry
Then the account is temporarily locked for 15 minutes and the user sees a lockout message with a support link

Criterion 5: Resend code

Given the user is on the 2FA verification screen
When they click "Resend code" and the cooldown period (60 seconds) has passed
Then a new code is sent to their phone and the previous code is invalidated

Non-Functional Criteria Checklist

☑ Performance. Code delivery via SMS within 10 seconds
☑ Accessibility. Code input field has label "Enter verification code" and supports paste
☑ Security. Codes are hashed server-side; rate limiting on verification endpoint
☑ Responsiveness. Verification screen works on mobile and desktop
☑ Error handling. Network failures show "Unable to verify. Check your connection."
☑ Analytics. Track 2fa_prompt_shown, 2fa_success, 2fa_failure, 2fa_lockout events
☐ Localization. Not required for MVP (English only)
☑ Browser support. Verified in Chrome, Firefox, Safari, Edge

Definition of Done

☑ All 5 behavioral criteria pass QA
☑ Non-functional criteria verified (6 of 7 applicable)
☑ Code reviewed by security team lead
☑ Unit tests cover verification logic, expiry, and lockout (92% branch coverage)
☑ API documentation updated with new /auth/verify-2fa endpoint
☑ Demo-ready for sprint review

Key Takeaways

One scenario per criterion. Combining multiple behaviors in a single Given-When-Then makes testing ambiguous and debugging harder.
Include edge cases and error paths. Happy-path-only criteria miss the scenarios that cause production incidents.
Use the non-functional checklist every time. Performance, accessibility, and security requirements are easy to forget if they are not explicit.
Write criteria before estimation. The number and complexity of criteria directly inform how many story points a story deserves.
Review with developers and QA together. A 10-minute walkthrough prevents days of rework.
Treat criteria as a living document. Update them if scope changes mid-sprint rather than shipping against outdated requirements.

Acceptance Criteria Template