Best Practices for the writing of the Acceptance Criteria
The acceptance criteria are key parts in the definition of the User Stories and their testing, not just mere accessories. Let's go and see some Best Practices on how to write them.
Acceptance criteria: why are they so important?
You know when you are in the checkout line at the supermarket and you feel like you have put everything you need on the belt?
Well, it may happen that immediately after paying and packing, you leave the shop and you realize that you have forgotten exactly what you came here for. And you curse yourself because you should have written down a shopping list.
In the User Stories scenario, the shopping list that you just can't do without is represented by the acceptance criteria.
"Acceptance criteria are predetermined standards or requirements that a product or project shall meet."
The User Story encloses a certain functionality seen with the user's eye, and to have a good User Story what we need is to have good acceptance criteria.
First of all to achieve the goals set in the planning phase: having clear requirements allow us to have a clear idea of what needs to be done, how to do it, determine the complexity and who are the figures involved. This leads to better synergy and also more effective communication.
And then, having clear and detailed acceptance criteria is part of the Definition of Done: it allows us to quickly and easily understand if the US is complete and meets the expected requirements. Basically, if it does the right thing: besides the technical aspects if the behavior it implements is also what we expect.
• Image of Agile Pain Relief.
Not surprisingly, according to the 2005 ESI International survey, 50% of projects used to failed due to poor requirements planning and communication issues: issues that can also be traced back to hasty and superficial work on acceptance criteria.
How to write acceptance criteria
At first glance, it might seem very simple to compile such a list, but in reality, the pitfalls are just around the corner. And working loosely on acceptance criteria means that bugs are more likely to show up.
Here are the best practices to always keep in mind.
1. Who, when, how?
Before we start writing and while we put it on paper (or on screen) we should always remember to wear the end-user’s shoes. This is usually put into the foreground by the Product Owner, but it must be a clear and shared aspect of the entire team. All before the US enters the sprint.
The language in which the acceptance criteria are expressed must be accessible, simple and concise. The central concept must be included in a short sentence, without extra details that could overload or make it harder to understand the meaning. Need a tip? Avoid conjunctions: follow the subject, verb and complement formula.
3. Testable, measurable, achievable
We always keep in mind the ultimate goal of the acceptance criteria: everyone should know the requirements to be met and verify that they are fully satisfied when the US closes. For this, each criterion must be independently testable, and its entirety must help us plan and estimate the US. Furthermore, the acceptance or failure scenarios must be crystal clear.
Is there a better format than the others? Let's say there are two most used writing methods: the one that provides the rules, a checklist, and the one that outlines the scenario, Given-When-Then: that is, given a certain prerequisite, when a certain event occurs, then I expect a certain situation as a consequence.
What matters is that, whatever format is chosen, even if fully customized, is known by all and crystal clear for the entire team. In 20tab, for example, we favor the definition of these requirements through examples and we write the scenarios in the Gherkin language, a fundamental choice for a team like ours, also made up of non-technical figures.
5. Shared understanding
And then, the latest best practice, but also the one underlying all the others: the acceptance criteria must be the "heritage" of the entire team. In the initial phase and in the analysis, all figures must have a clear understanding of what has been included in this list of requirements: shared knowledge is a key factor in the success of the work in the US, for the Product Team but also for the customer.
In this way, everything becomes more fluid, transparent and focused. And isn't that what the acceptance criteria are for?
Acceptance criteria and process
Remember that acceptance criteria are intentions and not solutions. They help us find bugs and solve several issues:
- they allow to clearly define the goal and keep it fixed;
- they clarify, break down and simplify concepts and requirements to keep in mind;
- they are the starting point for the tests and for the work of the QA Tester, who should, in fact, be present at their definition;
- they become a supportive tool for the team, which moves on the same wavelength and can do real teamwork.
This starts from the initial phase already, within a process that is not a journey, but a continuous cycle: the acceptance criteria are drawn up in the initial phase, monitored during development, verified in the final phase. And this is where we start again when something doesn't work.
Their real purpose is to avoid bad surprises upon release and to give the end-user a high-quality product and a pleasant experience.
In 20tab we work carefully on the acceptance criteria, clarified and shared by the entire team: for us this is a fundamental step, a first step towards the goal. Here you can discover our working method!