---
title: "Acceptance Criteria"
description: "Defining what \"done\" means"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.testandaccept.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Acceptance Criteria

Acceptance Criteria define the specific conditions that must be met for a work item to be considered complete. They're the answer to the question: "How will we know when this is done?"

## What are Acceptance Criteria?

Acceptance Criteria help you:

- **Define Success**: Clearly state what must be true for work to be considered complete
- **Align Expectations**: Ensure everyone understands what you're building
- **Guide Development**: Give developers clear targets to hit
- **Enable Testing**: Provide a basis for creating tests
- **Prevent Scope Creep**: Keep the work focused on what was agreed

Think of them as a checklist of conditions that must all be true before you can say "this is done."

## Criterion Properties

Each acceptance criterion has:

### Basic Information

- **Title**: A concise statement of what must be true (e.g., "User can log in with email and password")
- **Description**: More detailed explanation of the requirement
- **Task Item**: Which work item this criterion belongs to
- **Owner**: The person responsible for this criterion
- **Sort Order**: Where it appears in the list
- **Created/Updated**: Timestamps

### Relationship to Work

<pre class="mermaid">{`
flowchart LR
  Item[Work Item] -->|must meet| Criterion[Acceptance Criterion]
  Criterion -->|verified by| Test[Tests]

  style Item fill:#fff4e6
  style Criterion fill:#f3e5f5
  style Test fill:#e8f5e9
`}</pre>

Each work item can have multiple criteria, and each criterion can have multiple tests.

## Writing Good Criteria

### The Formula

A good acceptance criterion follows this pattern:

**[Actor] can/must [action] [result]**

Examples:
- "User can reset their password via email"
- "System must validate email addresses on submission"
- "Admin can view all user accounts"

### Be Specific

**✅ Good - Specific and measurable**:
- "Password must be at least 8 characters long"
- "Search results appear within 2 seconds"
- "User receives confirmation email within 1 minute"

**❌ Bad - Too vague**:
- "Password should be secure"
- "Search should be fast"
- "User gets notified"

### Be Testable

Every criterion should be something you can test:

**✅ Good - Can be tested**:
- "Form displays error message when email field is empty"
- "Page loads all data before showing content"
- "API returns 404 for non-existent resources"

**❌ Bad - Can't really test**:
- "UI should look nice"
- "Users should be happy"
- "System should work well"

### Focus on Outcomes, Not Implementation

**✅ Good - What, not how**:
- "User can filter results by date range"
- "System persists user preferences across sessions"
- "Dashboard displays last 30 days of activity"

**❌ Bad - Too focused on how**:
- "Use a React date picker component"
- "Store preferences in localStorage"
- "Query the database with a SQL WHERE clause"

## Common Formats

### Given-When-Then (BDD Style)

This format is great for user interactions:

```
**Title**: User login with valid credentials

**Description**:
GIVEN a registered user
WHEN they enter their correct email and password
THEN they are redirected to the dashboard
AND they see a welcome message with their name
```

### Checklist Style

Good for features with multiple requirements:

```
**Title**: Registration form validation

**Description**:
The registration form must:
- Require email, password, and name fields
- Validate email format
- Enforce password strength (8+ chars, 1 number, 1 symbol)
- Display field-specific error messages
- Disable submit until all fields are valid
```

### Simple Statement

For straightforward requirements:

```
**Title**: Password reset email delivery

**Description**:
When a user requests a password reset, they must receive an email with a valid reset link within 60 seconds.
```

## Types of Criteria

### Functional Criteria

What the system must do:

- "User can upload files up to 10MB"
- "System automatically saves draft every 30 seconds"
- "Admin can export data as CSV or PDF"

### Non-Functional Criteria

How well the system must perform:

- "Page load time is under 3 seconds"
- "System handles 1000 concurrent users"
- "Data is backed up every 24 hours"

### Negative Criteria

What should NOT happen:

- "Unauthorized users cannot access admin panel"
- "System does not store credit card numbers"
- "Deleted data cannot be recovered by users"

## Adding Criteria to Items

### When to Add Criteria

Add acceptance criteria:

- **During planning**: When defining what you'll build
- **Before development starts**: So developers know what to aim for
- **After requirements clarification**: When you understand what "done" means

### How Many Criteria?

**Rules of thumb**:
- Simple tasks: 2-5 criteria
- Complex features: 5-15 criteria
- If you have more than 15, consider breaking the item into smaller pieces

### Organizing Criteria

Use the sort order to group related criteria:

1. **Core functionality** (what it must do)
2. **Edge cases** (what happens in unusual situations)
3. **Error handling** (what happens when things go wrong)
4. **Performance** (how fast/efficient it must be)

## Criteria and Tests

### From Criteria to Tests

Each criterion should have at least one test that verifies it:

**Criterion**: "User can reset forgotten password"

**Tests**:
1. "Forgot password" link displays reset form
2. Submitting email sends reset link
3. Reset link allows password change
4. Old password no longer works after reset

### Multiple Tests per Criterion

Complex criteria might need several tests:

**Criterion**: "Form validation prevents invalid data"

**Tests**:
1. Test email validation rejects invalid formats
2. Test password validation enforces length requirement
3. Test phone validation accepts international formats
4. Test required fields show error when empty

## Tracking Progress

Criteria contribute to your SOW's overall completion:

- Each criterion can be marked as "met" or "not met"
- The SOW tracks what percentage of criteria are satisfied
- This counts for 30% of the overall SOW completion

You can see:
- Total number of criteria
- How many are met
- Which ones still need work

## Working with Criteria

### Creating Criteria

When adding a new criterion:

1. Pick the work item it belongs to
2. Write a clear, testable title
3. Add detailed description if needed
4. It will be added to the bottom of the list

### Reordering Criteria

You can drag and drop criteria to change their order. Common patterns:

- Most important first
- Logical flow (setup → action → result)
- Grouped by concern (all validation together, all errors together)

### Updating Criteria

As you learn more about the requirements, you can:

- Update the title to be more specific
- Add more detail to the description
- Split one criterion into multiple criteria if it's too broad
- Mark criteria as met when they're satisfied

### Deleting Criteria

Deleting a criterion also deletes all its tests. Only delete if:

- The requirement is no longer valid
- You're consolidating duplicate criteria
- You're replacing it with better-defined criteria

## Common Mistakes

### Too Broad

**❌ Problem**: "Feature must work correctly"
**✅ Better**: "User can save draft and return to complete later"

### Too Technical

**❌ Problem**: "Use bcrypt with salt rounds of 12"
**✅ Better**: "User passwords are securely hashed and cannot be retrieved"

### Multiple Concerns

**❌ Problem**: "User can log in, reset password, and update profile"
**✅ Better**: Three separate criteria, one for each concern

### Not Measurable

**❌ Problem**: "System should be user-friendly"
**✅ Better**: "New users can complete registration in under 3 minutes"

## Best Practices

### Do

- Write criteria before development starts
- Make each criterion independently testable
- Use clear, simple language
- Focus on what, not how
- Get stakeholder agreement on criteria
- Update criteria as requirements evolve

### Don't

- Write criteria after the work is done
- Make criteria dependent on each other
- Use jargon or technical terms unnecessarily
- Specify implementation details
- Set criteria in stone - they can change
- Have too many criteria per item

## Review Checklist

Before finalizing your criteria, check:

- [ ] Is it specific and unambiguous?
- [ ] Can it be objectively tested?
- [ ] Does it define success, not implementation?
- [ ] Is the title under 255 characters?
- [ ] Does the description provide enough context?
- [ ] Is it independent of other criteria?
- [ ] Does everyone understand what it means?

## Example: Complete Criterion Set

**Work Item**: "User Authentication Feature"

**Criteria**:

1. **User can log in with email and password**
   - Given a registered account, when correct credentials are entered, user is redirected to dashboard

2. **System validates credentials on submission**
   - Invalid credentials show error message without redirect
   - Error message doesn't reveal whether email or password was wrong (security)

3. **Account locks after 5 failed login attempts**
   - After 5 failures, account is locked for 15 minutes
   - User sees message explaining the lockout

4. **User can reset forgotten password**
   - "Forgot Password" link is visible on login form
   - Reset email arrives within 60 seconds
   - Reset link expires after 24 hours

5. **Session persists across page reloads**
   - Logged-in user stays logged in after browser refresh
   - Session expires after 30 days of inactivity

## Related Concepts

- **Items**
- **Tests**
- **Statements of Work**

Source: https://docs.testandaccept.com/concepts/criterion/index.mdx