Using acceptance criteria and scenarios with BDD

Question

TL;DR: We use rule-oriented and scenario-oriented acceptance criteria for test definition and clarity. Is this OK?

I am seeing more and more descriptions of stories where the user scenarios or bullet pointed acceptance criteria are used, but not both. E.g.:

1. https://medium.freecodecamp.org/the-acceptance-criteria-for-writing-acceptance-criteria-6eae9d497814
2. https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important

We use the scenarios to define what is required as functional change and for automated test definitions.

We use bullet pointed acceptance criteria to define yes/no human pass/fail conditions in as concise terminology as possible.

Having read this post I would like to know if it is appropriate to use both acceptance criteria and Scenarios in the same Behaviour-Driven Development stories?

I do it this way (as the Scrum Master) because it is how I was raised (in Agile) though I admit to finding difficulty in describing 'how to write bullet acceptance criteria' for my team.

Answer 1

TL;DR; Use what gives you value.

Many approaches including Acceptance Test-Driven Development (ATDD), Behavior-driven Development (BDD), and more broadly, Spec by Example, all use types of executable scenarios to address the same problem as Acceptance Criteria. (There's some academic debate on if calling these scenarios AC is appropriate, but I don't think it matters much practically).

In my experience, most teams using one of these approaches find that all necessary details can be expressed by a scenario. However, I have seen plenty of times where a particular need is in the scenarios but is unclear and so expressly stating it in a short statement adds clarity. Nothing about user stories counters this practice. In fact, I'd say it is well within the intent of User Stories.

The only word of caution I'd give is this: User Stories are intended to facilitate a conversation. If scenarios or acceptance criteria are being used to make sure that the "requirements" are perfectly clear so they can be passed off to the team without further conversation, this would be a pretty strong anti-pattern.