‘Acceptance criteria’ (AC) can always be interchanged with the terminology called ‘Conditions of Satisfaction’ (CoS)
Acceptance Criteria is a “Pre-defined rule to be met by the project or program acknowledged by a customer, user, or other participants involved in the development of the project/product.”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 clearly defined brief sentences, indicating clearly about the end result. Specifying the functional and the non-functional requirements, and they can be used at the Epic level, Feature level, and Story Level.
Acceptance criteria act as a facilitator for experiments and it must be tested. An acceptance criterion describes the elaborate need of the prerequisite that supports the developers to grasp the worth and enabling them to cut across the user story flat.
The CoS provides information to the developers regarding the outset of the project they should consider to complete a task. CoS supports the developers to divide the job into small and simple chunks and prepare user stories for them, the detailed acceptance criteria will enable the developers to understand the job better and hence they make the right user story, this will reduce the cycle time of the development process and also utilizes the assets efficiently.
Contents
Template for Agile Acceptance Criteria
Scrum does not support any template for the acceptance criteria. As we have already seen in the definition, Acceptance criteria is an elaborate explanation provided by the product owner about the system or the feature, user story must be checked and certified keeping acceptance criteria as a reference.
Importance of Acceptance Criteria
- Acceptance Criteria will keep the right content.
- It provokes the thought process of the team and awakens their inner conscious to think from the shoes of the customer.
- Enables the team to write the accurate test cases without any vagueness in understanding the business value.
When to write Acceptance Criteria
Avoid writing acceptance criteria after development has started as it leads to just validating that the functionality built works and not validating that the functionality meets user needs and expectations.
We must write and evaluate the acceptance criteria before execution starts, this will help us to capture the customer intent and not the development reality.
What should be in included in Acceptance criteria
- Unwanted consequences of the purpose.
- How does user story affect the other areas?
- Issues related to User experience design.
- Functional and non-functional use cases
- Issues related to the action and guiding principle.
- The arrangement tends to perform what action.
- Back-to-back user experience.
Types of Acceptance criteria
- Functional criteria
- Non-functional criteria
- Performance measures
- Defect indicator
Examples of Acceptance Criteria
- Online form submission
- I can submit the form by entering my name, surname, and email address.
- Upon clicking the submit button, its color changes from blue to green.
- The system notifies me regarding the confirmation email will be sent.
- If an empty form is submitted, an error message appears prompting 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 shop’s page informing about a successful subscription.
- Alternatively, I can copy the link to paste it into my browser.
- The system sends the email within 2 seconds.
- This function is offered to the admin groups, global user groups, power user groups, standard user groups.
The above example clearly shows that these acceptance criteria help to check if the developer has completed the task preserving user stories to the needed amount. Acceptance criteria also serve as a basis for writing test scenarios, to achieve high quality in QA and UAT.
- Customer request to send an email to a normal email address when his account goes into overdraft so that he knows that he need to put money into his account.
In the above example, Acceptance criteria are given as a set of statements representing the requirements CoS. It contains the restrictions and the constraints that regulate when a user story is completed and ready for acceptance. It is explained clearly in simple customer language without any uncertainty on what is expected as an outcome.
The development team once finishes working on the user story, they show the functionality to the Product Owner, explaining how each criterion is satisfied.
Practical Example of Acceptance Criteria – Image Courtesy – yodiz.com
Figure 1
How to create Acceptance Criteria
Acceptance criteria comprise of 3 parts:
Input – The inputs of acceptance criteria are typically like “entering a value and clicking a button” (Refer Example 1) or “entering a command and checking results” (Refer Example 2)
Process – The process is the step where actual computation being done. Usually, a user story is created when we look at some action for a given set of inputs by a user. While steps are not usually directly observable, in the process step it is verified for a given set of inputs and expected outputs.
Output
The output/outcome (results) of acceptance criteria must be testable with minimal uncertainty.
Acceptance Criteria Format
- Given some prerequisite or some context
- When I perform some action
- Then I expect some outcome or a set of observable consequences.
Given/When/Then to Validate requirements
Significance of Writing Acceptance Criteria Format
- Writing acceptance criteria in this format provides a consistent structure.
- It helps testers to determine when to begin and end testing for that specific work item.
When it is difficult to construct criteria using the given, when, then, format, using a verification checklist works well.
Characteristics of a good Agile Acceptance Criteria
Good Acceptance Criteria can benefit the Agile project by working as planning rather than working as coded.
How to write User Stories?
Who
What Action
End Result
Look at the example given below
Who – System admin, What Action – take a backup, Results format the system.
If no acceptance criteria, the no user story.Acceptance Criteria explains in details about the User story created.
Characteristics of a Right Acceptance Criteria
According to Microsoft, Acceptance Criteria is a “Pre-defined rule to be met by the project or program acknowledged by a customer, user, or other participants involved in the development of the project/product.” According to Google, Acceptance Criteria is a “Pre-established standard or requirement a project or product must meet.”
Characteristics of a good Acceptance Criteria must contain
Functional standards: Classify specific user functions, tasks or commercial procedures which must be rightly placed. The criteria must be “It is possible for a user to view the records of existing information.”On the other hand, criteria which are not functional must be “Workflow keys and Edit keys abide by the website key design.”
Non-functional Criteria: Find the situations which are not functional to be met during the execution like architecture features. Criteria which are not functional must be “Workflow keys and Edit keys abide by the website key design.”
Performance Criteria: Any important action which is required for the acceptance of a user story must be involved.Normally it is considered and measured as reverberation time, and must be intended as the outset like“Workflow keys and Edit keys abide by the website key design.”
Acceptance Criteria affirms the purpose, and not a result (e.g., ”A senior official can accept or reject a request instead of “A senior officer clicks Accept/Reject option to authenticate a request“).The phenomenon must be free from the execution: ideally, the terminology used must me the same irrespective of the method used.
Look at the example given below
The same example given in the start of Characteristics of a good Agile Acceptance Criteria is explained in detail.
Who – System admin, What Action – take a backup Results format the system.
Input: I can take a back up by giving the required details about the customer
- User ID
- Mail ID
- Contact No:
- Authorization ID
- Status of the account
- Details to be taken as backup
- Backup cannot be taken for obsolete data
- Backup cannot be taken if the system has got corrupted in the recent past and no recovery was done.
Process: The system sends a notification to me stating the reason for not able to backup or if the backup was taken it confirms the same with a mail sent to the customer who requested for a backup.
Output: I can chek with the customer regarding this action performed by the system.
Applying this technique to any Agile project can help for a quick transformation from “Worked as required” to “Worked as Planned.”
Methods to complete acceptance criteria
Acceptance criteria are not easily well-defined. Let us study about the most used methods to make sure all criteria are recorded:
- Six Thinking Hats
- 6-3-5 Method
- 5 Whys
- Changing Perspectives
Agile Acceptance Criteria Should Not Include the following
So far we have seen what needs to be done to make good acceptance criteria, now let us see what should not be included in acceptance criteria to make it more effective for your user stories.
- Code Review completion
- Major issues or Non-blocker
- Completion of Performance testing
- Completion of Acceptance and functional
All the above-mentioned details need to be included as part of DoD (definition of done), which is the checklist for overall sprint process.
Conclusion
When it is said user stories, it is always thought in terms of the user story description. The user story is complete only when it has a clear acceptance criterion. Acceptance criteria must be accompanied by every user story. An acceptance criterion decreases the risk for freelancers/contractors, particularly in fixed priced projects to differentiate the time span between the action and release. This helps them to make sure that the user story is done and ready for approval.
