Business Acceptance Criteria Fields

1. Name (required)

• What it’s for: A short, human-readable identifier for this acceptance criterion.

• What to include:

  • Keep it concise but descriptive enough that stakeholders can identify the criterion without reading the full specification.
  • Include the feature or capability context, e.g. Login — email and password authentication or Invoice submission — approval notification.
  • Avoid generic names like AC 1 or Happy path.

• Examples:

  • "Login — users can sign in with email and password"
  • "Invoice upload — file size limit enforced"
  • "Dashboard — redirected after successful login"

2. Description

• What it’s for: A plain-English statement of the acceptance criteria.

• What to include:

  • Use this field when the Given/When/Then structure does not fit naturally — for example, a policy constraint, a visual/UX expectation, or a non-deterministic outcome.
  • Can also be used alongside Given/When/Then to provide narrative context for business stakeholders who are less comfortable with the structured format.
  • Write from a business stakeholder’s perspective: “The solution must…” or “Users must be able to…”

• Example: "Users must receive a clear and informative error message if they attempt to log in with incorrect credentials."

3. Type

• What it’s for: Classifies whether this BAC covers a normal business flow or an error/exception condition.
• Options:

• Guidance: Acceptance Criteria should cover both paths. Exception BACs define what the business expects to happen when things go wrong — such as validation failures, rejected submissions, or system unavailability.

4. Given

• What it’s for: The pre-conditions or initial context that must be true before the action occurs.

• What to include:

  • The business state, user role, or context before the action.
  • Be specific enough to be unambiguous, but stay at the business level — avoid technical implementation detail.

• Examples:

  • "Given the user has a registered account"
  • "Given the invoice has been submitted for approval"
  • "Given the user's account has been locked after five failed login attempts"

5. When

• What it’s for: The action or event that triggers the business behaviour being specified.

• What to include:

  • The user action, business event, or system trigger.
  • Describe what the user does or what happens, not how the system implements it.

• Examples:

  • "When the user submits the login form"
  • "When the approving manager receives the notification email"
  • "When the user attempts to log in again"

6. Then

• What it’s for: The expected business outcome — what must be true after the action.

• What to include:

  • What the user sees, receives, or experiences.
  • The business result: confirmation, redirection, notification, data saved, process triggered.
  • Avoid specifying the technical mechanism — describe the outcome the business cares about.

• Examples:

  • "Then the user is redirected to their dashboard"
  • "Then the manager can approve or reject the invoice from the email link"
  • "Then the user is shown a message explaining their account is locked and how to unlock it"

Relationships