PremierAgile

Following an Agile approach, the Product Owner utilizes components such as User Stories and Acceptance Criteria for Product Backlog Management. Acceptance Criteria is the most critical component to define how the Developers should execute the development tasks. As an Agile Leader, this guide will help you understand Acceptance Criteria and how to write them!

Definition of Acceptance Criteria:

Acceptance Criteria are the product development conditions that Developers must satisfy to meet the end Product Goal. Otherwise, the results will not meet the Product Vision and User Expectations.

Each Acceptance Criteria statement either gets a clear pass or fail based on the functional and non-functional feature requirements. So we need to write well-defined Acceptance Criteria for User Stories per the client’s demands. It offers a uniform view of the product functionality per the Product Roadmap set by the Certified Scrum Product Owner.

Why Write Acceptance Criteria?

• Define the boundaries of each User Story to help the Development Team.
• Developers and stakeholders stay on the same page to meet the Product Goal.
• Acceptance Criteria act as the User Story acceptance testing to determine success/failure.
• The Scrum Master schedules development and testing tasks for the Agile Teams.
• Identify negative scenarios where the outcome doesn't match the expectations.

Who Writes Acceptance Criteria?

Acceptance Criteria establish a firm understanding between the Developers and the Product Owner to solve customers’ problems or create new product capabilities. The stakeholders and the Product Owner should write Acceptance Criteria collaboratively. But, the CSPO needs to understand client requirements first to present the Developers with a clear Product Roadmap. The Product Owner should document the Acceptance Criteria at the beginning of the project.

How To Write Acceptance Criteria?

Writing Acceptance Criteria isn’t as complex as you might think. These tips will help the Product Owner to save his valuable time.

Avoid Writing “Not”/”No”:

Write the user requirements without mentioning the “no” or “not” condition. Instead, rewrite the Acceptance Criteria in a clearer and verifiable way. 

Example:

Don’t: The application should have 90% availability all the time.

Do: The application must not fail.

Exception: Use “not”/”no” in Acceptance Criteria to add a logical objection. For example, “the login text should not be red.”

Use Active Voice:

Use active voice to clearly indicate the Acceptance Criteria based on the client requirements in the User Stories. Avoid passive voice sentences as it might sound unclear to the Developers about what they should do based on the Product Roadmap.

Avoid Using Pronouns:

Acceptance Criteria are kept in management tools like Jira as separate sets of statements in an unorganized manner. In such situations, using pronouns might sound ambiguous to the Developers. So it’s best to write the Acceptance Criteria with nouns instead of pronouns. 

Example:

Don’t: As a user, I want to share my information with others.

Do: As a user, I want to add a public profile description.

Avoid Using Conjunctions:

Conjunctions such as “but”, “and,” “or,” and “as well as” can make simple sentences look complex. These might break the requirements of Acceptance Criteria into several different conditions. So it’s best to avoid extreme usage of conjunctions in the Acceptance Criteria.

Example:

Don’t: The end users, as well as the stakeholders, should either be trusted or not trusted.

Do: The system should allow/decline the stakeholders and end users.

Exception: The Product Owner can use conjunctions to describe logical conditions.

Avoid Unattainable Absolutes:

Absolutes such as “100% availability” are unattainable because 100% system availability sounds unachievable. So the CSPO needs to write the Acceptance Criteria without using unattainable absolutes such as “all,” “never,” “always,” etc. 

Pro Tips On Writing Excellent Acceptance Criteria:

• Document the Acceptance Criteria before the Developers start the development process based on the given Product Backlog Item (PBI) and User Story.
• Express the intent of Acceptance Criteria with precise specifications. Don't narrow down the statements too short.
• Don't confuse the User Stories by making too long Acceptance Criteria statements to follow.
• Avoid complex technical terms in the Acceptance Criteria. Try to use simple language, easily understandable by any non-technical person.
• Depending on the stakeholders' viewpoints, reach a consensus on the problem statements. Communicate the Acceptance Criteria with the Scrum Team and development team members to mutually agree.
• Make sure to meet all Developers' and Testers' requirements so that the Acceptance Criteria sound testable by the integration team.

Main Challenges On Writing Acceptance Criteria:

• Trying to write the criteria during the ongoing development, testing, and integration activities.
• Narrowing down the criteria statements by eliminating critical information for the Developers.
• Using negative sentence constructions that might make the criteria sound unachievable.

Key Takeaways:

The stakeholders and end users must accept the Acceptance Criteria conditions for system-level functionality. The Scrum Master and Product Owner should document the Acceptance Criteria before the development and testing activities start. Remember to express clear intent of the Acceptance Criteria so that the Developers know the end Product Goal. 

Reference

1. https://www.linkedin.com/pulse/how-write-acceptance-criteria-examples-best-practices-/