Effective communication between clients and developers is the key to success in software development projects. If the clients’ requirements are fuzzy, developers can’t formulate their tasks accurately. Clear acceptance criteria, as other programming documentation, save time and lead to good results.
Generally, customer’s requirements are presented in the form of user stories and acceptance criteria.
A user story implies describing in simple terms the most common situations of using particular tools.
Acceptance criteria are different for each user story; they determine how the software or its particular parts will behave for the final user. Every software product should be delivered in agreement with the clients’ requirements — and these predefined conditions are known as acceptance criteria.
Let’s take a look at what problems can be solved with the help of acceptance criteria. This will improve your understanding of their nature.
Define user stories
Acceptance criteria contain clear information about the needed features, which helps developers to understand which user stories are already covered and which ones are still left.
Describe worst-case scenarios
A worst-case scenario is a situation when the user behaves in an unplanned way or submits incorrect data. Acceptance criteria should also cover these cases and explain the desired response of the system.
Achieve effective communication
Acceptance criteria help the development team and clients to achieve a common vision of the project. This way, there are fewer chances that misunderstanding and mistakes can occur during realization.
Enhance acceptance testing
Acceptance criteria are the core of user story testing. Every criterion has a positive and negative script, which can be checked with automatic testing.
Acceptance criteria let developers see the whole picture at once and identify the complexity of all tasks, which allows for better prioritization and better team performance.
Acceptance criteria can be given to developers in different forms — scenario-oriented and rule-oriented. Also, the format can be defined by the user.
The scenario-oriented format has the Given-When-Then structure and can be named as GWT. This is how it works:
Given some conditions;
When I do a certain action;
Then I expect a specific result.
With GWT, there is no need to write a testing scenario, which saves testers’ time. Acceptance criteria, in this case, consist of several parts:
Scenario: the name of the described behavior or situation.
Given: the primary condition of the described scenario.
When: a certain user’s action that should trigger a particular response of the system.
Then: the expected result of the user’s action or the correct response of the system.
And: any additions to any of the previous stages.
To make the matter clearer, let’s review an example:
User story: A user wants to register with the website.
Scenario: Registration with the website.
Given: The user is on the login page.
When: The user provides an email address.
Then: The system sends the link to the given email.
Given: The user receives the link.
When: The user clicks the link from the email.
Then: A page for generating a password opens.
There are many cases when scenario-oriented acceptance criteria are not effective, such as for describing design limitations when it is easy to skip important details. Also, it is not effective when user stories require different methods of quality control. In these cases, rule-oriented acceptance is used.
There is a set of rules, which describe system behavior and enable developers to create scenarios. In that case, criteria are given as a list.
For example, take this user story: A user wants to exploit a search box to find a post on the blog.
Acceptance criteria can be the following:
Acceptance criteria can also be presented in any form, e.g., as a text or a schedule. The main rule is that the criteria should be written clearly and explicitly.
There are no strict requirements who should write acceptance criteria. This can be a project manager, a business analyst, a requirements analyst, or a product owner. If clients have technical competence, they can write the criteria themselves and discuss them with a team of developers. It is better to start with the prioritization of user stories and after that agree on controversial points.
Acceptance criteria don’t seem a too complex notion to understand, but writing them can be a problem. There are some tips, which can make this process easier
If acceptance criteria were documented before development, the team can foresee all users’ needs immediately. These criteria are also involved in the technical process planning.
Particular acceptance criteria can lack some scenarios or be too specific.
It is necessary to differentiate critical conditions from unnecessary details. If there are many details, the development team will be overburdened with small tasks and hence will need more time to deliver the project.
Wide acceptance criteria blur a user story, and hence developers can’t plan their time and prioritize tasks properly.
Acceptance criteria should be written with simple words, clear for non-technical specialists, managers, or stakeholders.
Stakeholders and developers should make sure that they understand acceptance criteria alike since the same problem can be solved in different ways.
Written and accurate acceptance criteria help developers to understand whether particular user stories have been covered. Testers will also be able to check all requirements.
Writing acceptance criteria is an important part of the software development process.
It gives an understanding of the target behavior of the software, allows the development team to create a quality product, and helps the owner avoid bugs in the finished product.