As a Product Manager, ensuring that all stakeholders fully understand User Stories is one of your major challenges. BDD can help you to do so.
The User Story is the flagship artifact of Product Managers. Written, prioritized, detailed, estimated, developed, tested, and validated… it goes through a complete lifecycle before being set aside once its objective is achieved. Product Managers are responsible for the entire "preparation" phase of User Stories. You can check out Antoine's video on best practices for writing user stories. To give substance to your User Story, Romain recommends incorporating mock-ups. This is a practice I have always applied to my User Stories until… I worked as Product Manager on an API! Mock-ups were no longer of any help to me, and a new form of story enrichment saved my life: BDD, specifically the Gherkin language.
BDD and Gherkin in a Few Words
BDD (Behavior Driven Development) is an agile methodology proposed by Dan North to go beyond TDD (Test Driven Development). This methodology aims to improve understanding and collaboration among the Product Manager, developers, testers, and other relevant stakeholders by describing the expected behavior of the functionality using a common language: Gherkin.
This language, based on a standardized syntax, facilitates the reading of User Stories and standardizes acceptance criteria. The goal is not to paraphrase business rules but to provide precise examples. For each User Story, you can write one or more tests in Gherkin following this structure:
- GIVEN: the initial context at the test execution.
- WHEN: the event or action to be performed.
- THEN: the expected result.
These acceptance criteria illustrate by example what you expect from your software once the User Story is developed and can be supported by mock-ups. The development team will base the code related to the User Story on these acceptance criteria, and the tester will also use them to validate the story and mark it as done.
The "Three Amigos" Workshop and Scenario Writing
Among BDD best practices, "Three Amigos" workshops can be very beneficial. The important thing is not the number of participants but the diversity of profiles around the table. Ideally, a Product Manager, a tester, a developer, but also an operator or even a salesperson (depending on your product context) participate in this workshop and write the scenarios together after the Product Manager has presented a User Story.
These sessions help align the vision and ensure everyone understands the items. They also allow for a thorough examination of User Stories and ensure all expected behaviors (and thus all acceptance criteria) are planned. Though time-consuming, these sessions are important at the beginning of a project when the product starts to be developed. Over time, the team naturally starts speaking the same language, and the Product Manager (or the tester) can write the scenarios alone.
