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

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