What Characteristics Make Good Agile Acceptance Criteria?
Good Acceptance Criteria will help get your Agile project from “It Works as Coded” to “It Works as Intended.” Read on and see how.
A User Story is a description of an objective a person should be able to achieve, or a feature that a person should be able to utilize, when using a software application.
User Stories have been classically written in the following form:
As an <actor phrase > I want <action phrase> so that <outcome phrase>
As an Administrator, I want to be able to create User Accounts so that I can grant users access to the system.
A User Story cannot stand alone. It must be accompanied by “good” Acceptance Criteria to provide a way to clearly demonstrate if the Project Team has indeed made the User Story come true.
What Are These Acceptance Criteria and What Makes a “Good” One?
Microsoft Press defines Acceptance Criteria as “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” Google defines them as “Pre-established standards or requirements a product or project must meet.”
Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional (e.g., minimal marketable functionality) and non-functional (e.g., minimal quality) requirements applicable at the current stage of project integration. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.
These criteria define the boundaries and parameters of a User Story/feature and determine when a story is completed and working as expected. They add certainty to what the team is building.
Acceptance Criteria must be expressed clearly, in simple language the customer would use, just like the User Story, without ambiguity as to what the expected outcome is: what is acceptable and what is not acceptable. They must be actionable: easily translated into one or more manual/automated test cases.
Acceptance Criteria may reference what is in the project’s requirements documentation to provide details, but should not be a re-hash of what is in it. They should be relatively high-level. They should include:
- Functional and Non-functional Criteria: Identify specific user tasks, functions or business processes that must be in place at the end of the sprint or project. A functional requirement might be “When a user clicks on the ‘Reports’ dropdown, a list of available reports will be displayed.” A non-functional requirement might be “Form edit buttonswill be blue, and Form workflow buttons will be green.”
- Outstanding Defects: Clearly define what is acceptable for outstanding open defects: how/when most critical/high, medium, and low priority defects be addressed/corrected: during the current sprint/release or deferred to a later cycle.
- Performance: Usually measured as a response time, expected performance should be spelled out as a range such as “1-2 seconds for a query response.”
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.
Acceptance Criteria for the User Story at the beginning of this article might look like the following:
- If I am an Administrator, I can create User Accounts.
- I can create a User Account by entering the following information about the User: a. Name, b. Email address, c. Phone Number d. License Number (Power/Basic/None), e. Account Status (Active/Inactive), f. Reports to (from a list of "Active" Users)
- I cannot assign a new User to report to an “Inactive” User
- I cannot assign a new User to report to a User if it creates a cyclical relationship (e.g., User 1 reports to User 2 who reports to User 1
- The system notifies me that it sent an email to the new User's email address, containing a system-generated initial password and instructions for the person to log in and change their password.
- I am able to verify with the intended recipient of the email that it was received.
Apply these ideas to your Agile project and you will quickly transform it from “It Works as Coded” to “It Works as Intended.”