Acceptance Criteria

Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system. Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.

Acceptance Criteria may reference what is in the project’s other User Stories or design documents to provide details, but should not be a re-hash of them. They should be relatively high-level while still providing enough detail to be useful. They should include:

• Functional Criteria: Identify specific user tasks, functions or business processes that must be in place. A functional criterion might be “A user is able to access a list of available reports.” A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
• Non-functional Criteria: Identify specific non-functional conditions the implementation must meet, such as design elements. A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
• Performance Criteria: If specific performance is critical to the acceptance of a user story, it should be included. This is often measured as a response time, and should be spelled out as a threshold such as “

Acceptance Criteria should state intent, but not a solution (e.g., “A manager can approve or disapprove an audit form” rather than “A manager can click an ‘Approve/Disapprove’ radio button to approve an audit form”). The criteria should be independent of the implementation: ideally the phrasing should be the same regardless of target platform.

Writing Effective Acceptance Criteria

• Keep your criteria well-defined so any member of the project team understands the idea you’re trying to convey.
• Keep the criteria realistic and achievable. Define the minimum piece of functionality you’re able to deliver and stick to it. On the other hand, don’t try to describe every detail since you risk cluttering up your backlog and getting buried under many small tasks.
• Coordinate with all the stakeholders so your acceptance criteria are based on consensus.
• Create measurable criteria that allow you to adequately estimate development time so you’re able to stay within budget and time constraints.
• Consider providing checklists that enable you to see what user stories are covered with acceptance criteria.

source: RubyGarage

The Use of Acceptance Criteria

• To define boundaries. Acceptance criteria help development teams define the boundaries of a user story. In other words, acceptance criteria help you confirm when the application functions as desired, meaning that a user story is completed.
• To reach consensus. Having acceptance criteria synchronizes the development team with the client. The team knows exactly what conditions should be met, just as the client knows what to expect from the app.
• To serve as a basis for tests. Last but not least, acceptance criteria are a cornerstone of positive and negative testing aimed at checking if a system works as expected.
• To allow for accurate planning and estimation. Acceptance criteria scenarios allow for the correct division of user stories into tasks so user stories are correctly estimated and planned.

Characteristics of Effective Acceptance Criteria

• Testable with clearly defined pass/fail results

Have testable criteria. This allows testers to properly confirm that all of the desired conditions have been fulfilled. If criteria were not testable, then there would be no way for verification. These criteria should either be met or not met. A developer should know the point in which the criterion has been achieved. Any ambiguity may prolong effort on the story. For example, an acceptance criterion states “increase the number of entries available in a drop-down menu”. The developer would have no idea how many new entries to add and may take the liberty to assume a number based on his experience with the product. Likewise, a manual tester may take the same liberty and assume a different definition of increase. This results in a confusion that will circle back to the product owner.

• Unambiguous and concise

This is where writing acceptance criteria become an art. Academic essays stress the importance of clarity and succinctness. Similarly, writing acceptance criteria mandates the same level of organization and care. Similar to writing a literary piece, the audience must be kept in mind. Those reading the acceptance criteria must understand what is written. Otherwise, those words are completely useless. If they are long-winded and filled with jargon, then the main points of the outlined conditions may not come across. Many people can overlook essential details in a sea of words when pressed for time. Even when not pressed for time, many people can easily gloss over long blurbs. Instead of putting the blame on others’ lack of careful reading, one can proactively present acceptance criteria that are easy to read, straight to the point, and devoid of superfluous details.

• Establish shared understanding

This is probably the most important characteristic and the one most taken for granted. If all the members of the team are not on the same page, then process and productivity become jeopardized. Having the development team review acceptance criteria before moving forward with the story minimizes confusion. Clarifications should be made about the criteria, and the criteria should be updated accordingly.

Benefits of Acceptance Criteria

• The acceptance criteria enable the development team to identify the user story which they can use as a reference of whether the product functionality is as required. Since the user story is the primary objective of the software development process, therefore the team can use it to assess the progress and the product if it is as desired.
• Unity between the client and the development team is synchronized as the client has specific expectations from the team while the team has detailed scenarios of the development process and the final product required.
• The software development project is usually divided into tasks which after each are completed, it has to be confirmed that they meet the requirement of the project development scope and this is made possible by the use of the criteria of acceptance.
• Before any software begins to be developed, some planning is required and estimation of resources and time. Acceptance criteria allow easy division of tasks which can then be easily budgeted and assigned for time.

Further Reading

• Acceptance Criteria vs. Acceptance Tests – Know the Difference ThinkSys
• 7 Tips for Writing Acceptance Criteria with Examples Agile for Growth
• The Importance of Having Clearly Defined Acceptance Criteria in Your Projects Simplilearn