The PM Journal | Log 10
Using BDD to write User Stories
Working as PO/PM I have learned several ways to write a user story, and different times these ways worked for one team but not for another. But one that stands out is Given-When-Then format part of Behavior-Driven Development (BDD).
As part of being more explicit regarding what we want to achieve, this format explains all the steps a user will make, and that way we can easily understand the scenario to think of more criteria we should account.
To give you a short background, BDD was created by Daniel Terhorst-North and Chris Matts formerly from the Test-Driven Development (TDD). The idea behind BDD is to assist business and technology to work better together in a more Agile way when developing software. And facilitate the testing in an approach that clarifies what and how the scenarios should be tested considering user behavior.
You can learn more about Behavior-Driven Development (BDD) here.
Using Given-When-Then as a user story benefits the engineers to obtain more clarity of what should be developed. I follow the structure below:
As a [the person or role who will benefit from the feature]
I want [the feature]
So that [the benefit or value of the feature].
Given: [the initial context at the beginning of the scenario]
When: [the event that triggers the scenario]
Then: [the expected outcome]
But: [to describe unexpected behavior]
And: [the additional outcome that needs to be consider].
I also add two more items to the story:
Notes: [the extra relevant information].
Success: [the metric to identify success].
Here’s an example that I wrote. Notice that I had to make a few changes to hide sensitive information, somethings might not make sense to you but you can get an overall vision:
As a: nominator
I want to: have the ability to add media to an award
So that: it will be more personalized to the recipient.
Given: the nominator is in the award details
when: the nominator decides to add a media
then: the nominator should click in the media icon
and: the finder opens
and: the nominator selects a file
and: the file is uploaded.
Given: the nominator selects a file
when: the file uploads
then: the validation should happen in terms of size and format
but: if invalid
then: the nominator should see an error message.
Support of a third-party company
Ability to upload videos of up to 400mb
We know this is true when we see an increase of X% in the newsfeed.
Our discussions during refinement are easier because the story is well defined and very clear. It helps us to be concise. And it is a well-known approach that engineers use. Especially testers, speeding up and facilitating their test case conceptions. Sometimes they add to the user story Alpha, Bravo, etc. to simplify the division of scenarios for test cases.
As we do our bests to create the product collaboratively, the engineers are already familiar with the product outlines, giving them autonomy to edit, make suggestions, and write backlog items following this format.
Another good practice is to involve testers when writing a user story. What I do is, instead of creating meetings that were harder with two teams, every time we have a new user story I share with the specific tester in the team and get their opinion. So when they read the scenarios using BDD, it helps them to think of edge cases and happy scenarios in case I missed something.
It is a win-win 🙂
(Please notice that I’m not native in English and I apologize for mistakes)