Acceptance Criteria in Scrum: Explanation, Examples, and Template
In this post, we explore the Scrum concept of Acceptance Criteria, and how they help dev teams create better code and products.
Join the DZone community and get the full member experience.
Join For FreeIn any software development process, a client’s communication with the development team is essential in creating a solution to the product requirements. Therefore, ambiguity in the client’s explanation of their requirements, such as, “I require an antivirus that is fast and awesome” limits the development team's understanding of the client's needs, and hampers the complete fulfillment of the product functionality. That’s why we feel that writing all-embracing user stories through well-defined acceptance criteria is key to any software development project that has become a commercial success.
The main aim of a client’s need to develop a software product is for it to fulfill certain requirements for the end user. For instance, an app that is able to send messages from one user to another. For the product to fulfill its user requirements, the client needs to fully, and in detail describe, their expectations. That is where the use of criteria of acceptance comes in.
Acceptance Criteria Definition
Acceptance criteria are a formal list that fully enumerates user requirements and all the product scenarios put into the account. Acceptance criteria plainly describe conditions under which the user requirements are desired, thus getting rid of any uncertainty of the client’s expectations and misunderstandings.
Acceptance criteria state the intent of the client and not the solution; it is up to the team to understand them and ask for clarification where it’s complex and find the solution.
Acceptance Criteria and User Stories in Agile
Scrum is a technique that enables the software development team to work with agile acceptance criteria and user stories to solve the toughest problems that arise during a sophisticated development process. User stories are generalized details of the user requirements of the system and what the client hopes to gain from this functionality. Therefore, Scrum uses user acceptance criteria to simplify the understanding of the client’s intent.
Benefits of Acceptance Criteria to Software Development Teams
The acceptance criteria enable the development team to identify the user story which they can use as a reference of whether the product functionality works as required. Since the user story is the primary objective of the software development process, the team can use it to assess the progress and the product.
A common understanding 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 requirements of the final product.
The software development project is usually divided into tasks, and, after each is completed, it is confirmed whether they meet the requirement of the project development scope. This is made possible by the use of the acceptance criteria.
Before any software begins to be developed, planning and the estimation of resources and time are required. The use of acceptance criteria allows for the easy division of tasks, which can then be easily budgeted and assigned.
How to Write Acceptance Criteria
Who and When
Since the acceptance criteria concerns the client and the team, it is either the client or a member of the development team that is supposed to write it. However, the client is the one who mainly writes it, especially if they have adequate knowledge of software development and acceptance criteria writing. For such criteria, a member of the dev team then looks at it to ensure that it is clearly documented and that there are no technical misunderstandings that may hinder proper software development.
In case the client is not adequately familiar with criteria writing or software development, they can assign the task to a person with technical expertise such as a project manager, requirements analyst, or product owner.
It would be disorienting to write acceptance criteria once development has started. Acceptance criteria is documented and completed before the project begins, as the team and the client come to an agreement on the smallest amount of work that will meet the client’s requirements.
What’s Good Acceptance Criteria?
Acceptance criteria are defined as good when the end product is as expected by the client and fulfills the user requirements. Therefore, it must be executable, and, for this to happen, it has to be written in clear, simple language that can easily be translated to a manual or automated test cases with no ambiguity on the expected output.
Tips on Writing Good Acceptance Criteria
Just like any process’s goal, the criteria should describe achievable and sensible information. It should provide the minimum level of functionality the product is to achieve, allowing space for some flexibility. Acceptance criteria should not be overestimated or underrated, but set at a realistic level.
Great criteria are well detailed and defined so that the team members can easily comprehend what is required of them and easily employ the information in development.
Acceptance criteria ought to have a standard of measurement that is to be used to gauge the progress of product development.
Any criteria should be based on consensus between the client and the team. The two parties will have different solutions to the same issue but acceptance criteria will help them reach a shared solution.
Just as the project is divided into tasks with the help of acceptance criteria, the criteria should also have a reference checklist to see whether the user story is covered.
How Acceptance Criteria Affects the Development Process
It is rare for the software development process to go as planned, especially for complex products. Nevertheless, making numerous changes in the process can result in a lot of expenses and wasted time. But with the help of acceptance criteria, the team is able to progress faster and fluidly as the project scope and the end product are well documented. The team and the client can easily assess the progress of development and look out for any mistakes by referring to the acceptance criteria, and if there are any they can easily correct them.
Examples of User Stories With Acceptance Criteria
This part it is about presenting “conditions of satisfaction” whereby all the possible conditions are covered, as well as the process and the end results. Typically any condition passes through the path/format like so:
As a (user) I can (function) so that (rationale/ achieve some result).
Here are some examples of user story acceptance criteria:
Example User Story:
- As a Harvard University student
- I can see my fee for the semester
- so that I know the remaining balance
Acceptance Criteria for This Example:
- The semester fee balance is displayed.
- The semester fee balance is calculated.
- The fee balance is displayed for that semester duration.
- The balance is not displayed if an unknown student identity is applied.
Example User Story:
- As a PayPal account holder
- I can withdraw my pending credit from PayPal
- so that I can have money in my Oschadbank account
Acceptance Criteria for This Example:
- I can see on Paypal account that there is pending credit.
- I can choose what amount of credit to withdraw.
- I can see my Oschadbank account balance when I have chosen to withdraw credit.
- I can’t tap into the Oschadbank account when there are no pending credits in my Paypal account.
Acceptance Criteria Template
Acceptance criteria describe the intent of the client, i.e. his/her idea of what the user story should be like. It is up to the team to develop the solution to the user story. To make it simple, they can divide the document into a three-part scenario: Given, When, Then – each describing an item of the criteria, like what the product is used for, what should be there and what shouldn’t be. In the format of acceptance test criteria examples:
Scenario | This is the title of the condition to be acted upon. |
Given (an initial condition) | The user places an item into their shopping cart. |
When (something happens) | This is where the process in which the user's initial order is verified or whether it fulfills the system requirements to process the task. If it does, then the system can proceed to work on the order. However, if the user order does not match to the system requirements, the system will deny the task. |
Then (this is the result) | Once the system is done verifying the user order, the order is then processed to produce the results which would be: the final result, input to the next task or a lead-on for the user to the next task. |
Examples of Filling in This Template
Scenario: Sending a message through a valid email address.
Given | The email address is valid. |
When | The email address is authenticated. |
Then | The message is sent to the email address. |
Scenario: Sending a message through an invalid email addresеs.
Given | an invalid email address. |
When | the email is authenticated. |
Then | the online profile is flagged as incomplete, kickoff snail mail message. |
In Conclusion
By giving your development team detailed and concise acceptance criteria, that both of you agree upon, will make the process of your product development very simple.
However, simple does not mean easy, it will require use methodologies like Scrum; an Agile framework which makes the complexity of the development processes a bit simpler for the team to understand and work on.
Feel free to leave your comments on your experience with acceptance criteria for user stories; we appreciate your feedback as well as any new ideas you may have.
Further reading
Published at DZone with permission of Victor Osetskyi, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments