Gherkin style Acceptance Criteria in User Stories
Let’s be honest, writing acceptance criterias is hard. The discussions about them with your team can be crushing. Every little word is picked apart. And you just feel exhausted afterwards.
The problem is usually not in the user story itself, but in the acceptance criteria definitions. Acceptance criterias are the conditions that the application must meet, in order to be accepted by the user. They are a contract between the users and the development team, with the product owner as an intermediary. Hence the development team wants to have clear and ideally verifiable acceptance criteria. Which can be challenging to write for a product owner.
One approach for acceptance criteria that I found very useful, and that works very well in my past projects is writing acceptance criteria in a Gherkin style syntax, that is usually used in Behavior Driven Development (BDD). So instead of writing an acceptance criteria like ‘User can login to the system’, you could express it in a Gherkin style like this:
Given the user is logged into the system
When they enter their username and password and press the login button
Then they are logged into the system and can access their orders
The big advantage of this approach is, you are talking about the behavior of the system from a user perspective. Instead of trying to indirectly map what you want to achieve, the team can build test cases for exactly those scenarios.
