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 I want so that
For example:
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, however. 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 testable: easily translated into one or more manual/automated test cases.
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 “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.
An Example
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.”