Best Practices for writing Acceptance Criteria

Acceptance criteria: why are they so important?

Do you know that feeling when you are in line at the supermarket’s checkout, and you think you’ve put everything you need on the conveyor belt?

Well, there's a moment, right after you've paid and bagged your items, when you step outside the store, and just a few steps away, you realize you've forgotten the one thing you came in for. And you curse yourself because you should have written a shopping list.

In the world of User Stories, the indispensable shopping list is represented by acceptance criteria.

"Acceptance criteria are predefined standards or requirements that a product or project shall meet."

The User Story is a very simple text that encloses a specific functionality from the user's perspective, and to have a good User Story, you need to have good acceptance criteria.

Why?

First of all, to achieve the goals set during the planning phase: having clear requirements allows us to understand precisely what needs to be done, how to do it, determine complexity and identify the involved parties. This leads to better synergy and also more effective communication.

And secondly, having clear and detailed acceptance criteria is part of the Definition of Done: it enables us to quickly and easily determine if the User Story is complete and meets the expected requirements. Basically, it makes sure that it does the right thing: besides the technical aspects, if the behavior it implements aligns with our expectations.

It is not a coincidence that, according to the ESI International survey of 2005, 50% of projects failed due to poor requirements planning and communication issues: critical factors also linked to hasty and superficial work on acceptance criteria.

How to write acceptance criteria

At first glance, compiling this sort of list might seem very simple, but in reality, pitfalls are just around the corner. Working somewhat loosely on acceptance criteria leads to failures.

Here are the best practices to always keep in mind.

1. Who, when, how?
   
   Before we start writing and during the documentation process (whether on paper or on the screen), always remember to adopt the perspective of the end-user. This is usually emphasized by the Product Manager but should be a clear and shared aspect among the entire team. All of this should be done before the User Story enters the sprint.
   
2. Clarity
   
   The language used to express each acceptance criteria should be accessible, simple and concise. It’s essential to capture the core concept in a short sentence, avoiding extra details that could overload or lead to misunderstandings. A piece of advice? 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.
   
4. Format
   
   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 (via Gherkin language): 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 potential bugs and solve several open issues:

• they allow to 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, refined in the PBR (Product Backlog Refinement) meetings, 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 acceptance criteria, clarified and shared by the whole team: for us it is a fundamental step, a first step towards the goal. You can discover our working method here!