Writing Effective Acceptance Criteria

Acceptance Criteria Overview

Acceptance Criteria, also called "Conditions of Satisfaction", are items that a user story must meet in order to deliver the functionality agreed to by the Product Owner. They provide the necessary details to define the boundaries of a user story, but in contrast to Definition of Done, Acceptance Criteria are unique and specific to each story.

Acceptance Criteria provide the outline for developers and testers to understand functional and nonfunctional aspects of a user story. They aid in estimation and evaluation of whether a story is completed and working as intended.

Goals of Acceptance Criteria

• Describe business requirements in such a way that the development team and the business owner come to a mutual understanding of the goals of a story or feature.
• Define the scope and both functional and non-functional boundaries of what will be delivered.
• Develop a list of items that the Product Owner will approve through story acceptance testing.
• Detail the what, not the how for each user story.

How to Write Acceptance Criteria

Acceptance Criteria can be written in many different formats and teams may prefer one format over the other. The key here is to agree as a team what makes the most sense based on the type of requirements, so that the Acceptance Criteria result in mutual understanding between the Product Owner and development team.

• Verification Checklists

  • Best when there are a lot of requirements or functionality for a single story
  • Easy to individually mark as complete
  • Example:
    • User Story: As an HR employee, I want employees to be onboarded automatically so that I can save time and avoid extra paperwork
    • Acceptance Criteria:
      • Verify that when a new employee emails his/her offer letter to HR, HR is required to enter the new hire’s name, salary, department, and manager
      • Verify that the new hire’s salary must be greater than $0
      • Verify that once HR enters the above information, they must indicate if the new employee is a college hire
      • Verify if HR indicates the new employee is a college hire, then HR must select a current employee with less than 2 years of experience to be the new hire’s mentor
      • Verify if HR indicates the employee is not a new college hire, then selection of mentor is optional
  • While multiple criterion are needed per story to ensure all angles are covered, a large number of acceptance criteria is a good indication that a story can be broken down into several smaller stories

• Given-When-Then

  • Best when using real-life examples (specification by example)
  • Drives out edge cases
  • Be mindful of creating criteria that are too long and difficult to maintain
  • Include 1 "When" statement for each acceptance criteria
  • Example:
    • User Story: As an HR employee, I want employees to be onboarded automatically so that I can save time and avoid extra paperwork
    • Acceptance Criteria #1:
      • Given a new employee has accepted his or her offer
      • When the new employee emails his or her signed offer letter to a recruiter
      • Then HR should be prompted to enter the new employee’s name, salary, department, and manager
    • Acceptance Criteria #2
      • Given HR has entered general on-boarding information
      • When HR indicates the new employee is a college hire
      • Then HR must select a current employee with less than 2 years of experience to be the new hire’s mentor

• Truth Tables

  • Useful if there is a lot of complex business logic (e.g. expressing specifications, state machine transitions, and calculation based rules)
  • Do not replace acceptance criteria with a truth table; truth tables supplement the acceptance criteria. Other supplements can include mockups, process flow diagrams, and sample inputs/outputs for integrations.
  • Be sure to use real-life examples
  • Avoid using mathematical notations (+/-, <, >, etc.) to be explicit and eliminate ambiguity
  • Example:
    • User Story: As an HR employee, I want employees to be onboarded automatically so that I can save time and avoid extra paperwork
    • Acceptance Criteria:
      • Verify when HR is choosing the new employee’s role, the logic follows the truth table below:

Employee Role Table

Questions to Answer with Acceptance Criteria

Who Writes Acceptance Criteria

When writing Acceptance Criteria, it is important to take different team members’ opinions into account to gain a more well-rounded view of the story. Therefore, we suggest writing Acceptance Criteria as an entire Delivery Team, so all parties interpret the story similarly and there are no surprises. As an alternative, one member of the team could write a draft of the Acceptance Criteria, and then hold a meeting with the PO and the rest of the development team (using the Three Amigos Concept) to groom, review, and finalize the Acceptance Criteria for the story together. In either case, the PO must give the final approval.

When Should Acceptance Criteria be Written

It’s important that Acceptance Criteria are written, agreed upon, and finalized with the Product Owner before estimation and story pointing occur. Acceptance Criteria give the team insight into what the story requires, allowing developers to consider dependencies and risks to give more accurate levels of story pointing.

Changes to Acceptance Criteria after a sprint begins should be minimized as much as possible. Generally, if the update to the Acceptance Criteria is large and would change the originally pointed scope, the team should develop the original story as planned and create a new story to capture the additional requirements. The new story can then be prioritized and added to a future Sprint without putting the current Sprint’s goal at risk. Alternatively, if the new requirements are absolutely necessary, the entire story can be pulled from the Sprint and brought into a future Sprint that has enough capacity to complete it.

Best Practices

Example

Benefits of Acceptance Criteria

• Benefits of Acceptance Criteria
  • Establish an agreement between the Product Owner and Development Team on the functionality that will be delivered to eliminate surprises upon delivery
  • Uncover and address assumptions about functionality before development begins
  • Aid in proper story estimation
  • Simplifies verification and change management
  • Helps make a team more efficient, as estimation is more accurate, additional scope is uncovered and addressed up front, and rework due to misunderstanding is reduced or eliminated
• Risks of Not Using Acceptance Criteria
  • Estimation becomes more difficult without acceptance criteria
  • Expected functionality may differ from what is actually developed
  • Additional scope is more frequently uncovered during development may put sprint commitments at risk