August 3, 2023, by Gabriele Giaccari
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.
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.
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.
Remember that acceptance criteria are intentions and not solutions. They help us find potential bugs and solve several open issues:
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!