Author:  David Kidd
Date:  11/24/2023

1. Scenario-Based Criteria

This approach focuses on defining specific scenarios or situations that the feature needs to handle. It’s great for capturing real-world use cases and how the system should behave in each. Think of it as storytelling for software behavior.

Example:

• Scenario: Successful Login
  • Given: The user is on the login page.
  • When: They enter valid credentials.
  • Then: They should be directed to the dashboard.

Benefits:

• Easy to understand and validate with stakeholders.
• Covers edge cases effectively when you write multiple scenarios.
• Helps teams think through “what happens if...” situations.

When to Use:

• When you want to focus on user workflows or behavior patterns.
• Ideal for features with multiple outcomes depending on user input.

2. Rule-Driven Criteria

Instead of focusing on behavior, this method sets specific rules or conditions that the system must adhere to. It’s like writing a checklist of “must-follow” guidelines for the feature.

Example:

• User inputs must be validated for required fields.
• Accounts should lock after three failed login attempts.
• Confirmation emails must be sent upon successful registration.

Benefits:

• Perfect for features that are more technical or rules-based.
• Makes it easy to define system constraints and non-negotiable functionality.
• Keeps the team aligned on what the system must do.

When to Use:

• When defining system logic, validation rules, or compliance requirements.
• Great for features where behavior depends on strict conditions.

3. Checklist Format

If you’re looking for simplicity, this format is your go-to. It uses straightforward bullet points to list the criteria, which is especially helpful for smaller or less complex features.

Example:

• The user must input a valid email address.
• An error message should appear for invalid inputs.
• The login button should remain disabled until all fields are valid.

Benefits:

• Quick to write and easy to read.
• Focuses on key points without getting bogged down in detail.
• Useful for teams that prefer brevity over structure.

When to Use:

• For straightforward features with clear, limited functionality.
• When you need something lightweight that gets the point across quickly.

4. Plain Language BDD

This is like Gherkin but without the formal syntax. It focuses on describing behavior in clear, conversational language, making it accessible to both technical and non-technical stakeholders.

Example:

• If the user provides incorrect login details, show an error message.
• If the user provides valid credentials, allow them to access the dashboard.

Benefits:

• Eliminates the rigidity of Gherkin while keeping the same intent.
• Easier to adopt for teams unfamiliar with Gherkin syntax.
• Focuses on behavior while being inclusive for all stakeholders.

When to Use:

• When the team prefers a simpler alternative to Gherkin.
• For teams that want behavior-driven criteria without a learning curve.

5. User Story-Centric Criteria

This ties directly to user stories, providing context and ensuring the acceptance criteria align with user needs. It’s a natural fit for teams working in Agile environments.

Example:

• User Story: As a user, I want to reset my password so I can regain access to my account.
• Acceptance Criteria:
  • A “Forgot Password” link must appear on the login page.
  • Clicking the link should send a reset email to the user’s registered email address.

Benefits:

• Keeps the user’s perspective front and center.
• Ensures the feature aligns with the “why” behind the story.
• Encourages teams to think about the value delivered to the end user.

When to Use:

• For Agile teams working with user stories.
• When you want to emphasize the user’s goals and motivations.

6. Use Case Specifications

This method dives deeper into the steps of how a feature will function, detailing the interaction between the user and the system. It’s great for more complex workflows.

Example:

• Actor: Registered User
• Trigger: User clicks the “Forgot Password” link.
• Preconditions: The user is on the login page.
• Steps:
  1. User clicks “Forgot Password.”
  2. System prompts the user to enter their registered email.
  3. User enters their email and submits the form.
  4. System sends a password reset email.
• Postconditions: The reset email is successfully sent.

Benefits:

• Provides a complete picture of the user’s journey and system interaction.
• Helps identify preconditions and dependencies.
• Useful for complex features that require step-by-step clarity.

When to Use:

• For features with multiple steps or interdependencies.
• When you need detailed documentation for development or QA.

7. Visual Acceptance Criteria

When features are UI-heavy, this method pairs textual descriptions with mockups, wireframes, or diagrams to give the team a visual reference.

Example:

• Login Page Requirements:
  • A text box labeled “Email Address” (see Wireframe A).
  • A password input field with masking functionality (see Wireframe B).
  • A “Forgot Password” link below the login form.

Benefits:

• Reduces ambiguity for design and development teams.
• Makes it easier to align expectations, especially for UI elements.
• Ensures consistency between requirements and the final product.

When to Use:

• For features that are primarily visual or design-driven.
• When you want to minimize misinterpretation of UI requirements.

Each of these methods can be tailored to fit your team’s workflow and the project’s complexity. In some cases, combining approaches—like using rules-based criteria alongside visual references—can offer the best of both worlds. At the end of the day, the goal is to write acceptance criteria that are clear, actionable, and aligned with the team’s goals.