On a project I am currently working on, something popped up — Acceptance Criteria (AC). It sounded foreign to my team, but apparently they know it as ‘Conditions of Satisfaction’ (COS). However the silver lining is they know what it means; whether called AC or COS; they know that it defines how a particular feature could be used from an end user’s perspective.
AC or COS are “Pre-defined rules that the project or product must meet in order to be acknowledged by a customer, user, or other parties engaged in the project’s/product’s development.
Tip: If it is related to a system function then it has to be accepted by the system where it is to be used.
Acceptance criteria could draw a line that makes it clear to team members what is and isn’t covered by the user story’s scope. In addition to guiding product behaviour in happy path scenarios, the user experience is also guided by the user experience acceptance criterion when things don’t go as planned. It describes what the acceptance tests would verify.
Acceptance criteria must be tested since they facilitate experiments. An acceptance criterion describes the specific requirements of the precondition that helps the developers understand the value and gives them the ability to cut across the user story flat.
Acceptance Criteria are brief, clearly stated statements that describe the intended outcome. They can be used at the Epic level, Feature level, or Story level, and they allow for the specification of both functional and non-functional requirements.
Note To Self
Scrum does not support any acceptance criterion templates. As we saw in the definition, acceptance criteria are detailed explanations of the system or feature provided by the product owner. User stories must be validated and certified using acceptance criteria as a guide.
Functional Acceptance Criteria: Identify the user tasks, functions, or business processes that must be in place.
Non-functional Acceptance Criteria: Identify the non-functional requirements, such as design requirements, that the project/product implementation must meet. It should also be provided if a specific performance is necessary for a user story to be accepted.
Acceptance criteria should not be based upon:
- Code Review was done
- Non-blocker or major issues
- Performance testing performed
- Acceptance and functional testing done
Importance of Acceptance Criteria or COS
“There is no partial acceptance: either a criterion is met or it is not.”
- Acceptance Criteria will maintain accurate content. In more words, it adds certainty to what the team is building and what is going to be delivered to users.
- The team is challenged to think critically and is made conscious of the need to put themselves in the user’s position.
- Like the User Story, the Acceptance Criteria must be presented in plain, everyday language that the user would understand, without any ambiguity regarding the expected outcome.
- Helps the team create precise test cases without any confusion regarding the business value.
- Acceptance criteria ensures Functional and Non-Functional completeness of the product.
Tip: Similar to Agile, AC is dynamic and can be modified over the course of the sprint as the user story is further refined.
- It assists in addressing the two most important questions in software development: “Did we build the correct product? Did we build the product correctly?”
What To Include In Acceptance Criteria
- Negative scenarios of the functionality.
- The impact of a user story to other features.
- User experience concerns (issues relating to it).
- Functional and non-functional use cases.
- Performance concerns and guidelines.
- What the system/feature intends to do (perform what action).
- End-to-end user flow
Writing Acceptance Criteria
Writing effective acceptance criteria is a vital component of creating strong user stories. Effective testing of the developed functionality depends on it. It enables team members who are building acceptance tests to comprehend the user story’s or product backlog item’s scope.
These Acceptance Criteria tips have been used as a checklist by some of the Scrum teams I’ve worked with to help them write good acceptance criteria. A checklist of acceptance criteria promoted consistency and served as a set of guidelines for new team members. I encourage the teams to keep revisiting and revising these tips as necessary to meet their needs.
Tip: I would caution against applying these suggestions as unbending rules.
Tip: Do not think of skipping or taking the task of writing acceptance criteria lightly (Trust me, it comes back to bite you).
- Each user story or item on the product backlog needs to have at least one acceptance criterion.
- It focuses on the outcome – WHAT. Not the method to the solution – HOW.
- It should go without saying, yet teams routinely forget to write acceptance criteria before implementing a project.
Tip: After project implementation, you write the acceptance criteria at an advantage.
- It is possible to test each acceptance criterion separately.
- Criteria for acceptance must have a clear Pass/Fail outcome.
Tip: Write large, complex sentences at your own risk.
- When appropriate, include both functional and non-functional criteria.
- The product owner verifies the acceptance criteria that the team members have written.
Tip: This can be done by both the development team and the product owner. It verifies that the PO and the team understand the user story in the same way.
Example of Acceptance Criteria
I will be making use of acceptance criterion I have used in my projects.
As a teacher, I want to be able to generate, so that I can evaluate student performance.
- Show a student’s current assessment score.
- Display the past assessment score of the student.
- Provide an option to Print / Save / Share.
- Display error message if service not responding.
As a user, I want to be able to view my statement/account balance, so that I can keep track of my transactions.
- Display statement balance upon authentication.
- Display total balance.
- Show pending payments.
- Show pending payment due date.
- Show payment approvals.
- Show error message if service not responding or timeout.
For example: “Sorry, something went wrong with the service. Please try again.”
As a user, I want to be able to view the online form, so that I can indicate my interest and submit.
- I can submit the form by entering my name, surname, email address and clicking reCAPTCHA.
- Upon clicking the submit button, its color changes from orange to black.
- The system notifies me regarding the confirmation email will be sent.
- If an empty form is submitted, an error message appears prompting me to enter name, surname, and email address.
- After submitting the form, a double-opt-in-email will reach my email address to confirm the subscription.
- Upon clicking the confirmation link in the double-opt-in-email, I will be forwarded to the website informing about a successful subscription.
- Alternatively, I can copy the link to paste it into my browser.
- The system sends the email within 3 seconds.
Acceptance Criteria Format
Just as I previously stated, project acceptance criteria describe the client’s goal, or his or her view of how the user story should be, and it is up to the team to build the primary story’s solution.
To make things easier, they can divide the content into scenarios that are made of the terms; Given, When, and Then, each of which describes a certain piece of the criteria, such as what it is used for, what should be present, and what shouldn’t be.
- Given some prerequisite or some context.
- When I perform some action.
- Then I expect some outcome or a set of observable consequences.
User story descriptions are always considered when the term “user stories” comes up. Only when the user story has a clear acceptance criterion can it be considered completed. Every user story must be accompanied by acceptance criteria. For freelancers and contractors, an acceptance criterion reduces risk, especially in fixed-priced projects to distinguish the period between the action and release. By doing this, they can make sure the user story is finished and prepared for approval.
Many teams include creating acceptance criteria for User Stories on their User Story Readiness Checklist to make sure the AC is established upfront for each user story. User Stories cannot be included in the Sprint Planning itself if they do not have at least one AC.
Well, that shouldn’t stop the team from exploring the intent or fine-tuning the AC after the Sprint Planning / before the project/product implementation when the team members talks with the Product Owner.
If you really like my posts on Software Testing and Quality Analysis, please support by subscribing or sharing my blog/channel. Feel free to share your thoughts in the comments section below as I learn just as much from you as you do from me.