What is a User Story?
A user story is referred to as an explanation of functionality written from the end-user perspective. Outlining requirements via a user story helps to clearly explain the value the feature brings to the end user. These stories are usually written in a non-technical language and can be used by the development team as a guideline to implement the feature. In an agile framework, a user story is the smallest unit of work.
What is Behavior Driven Development (BDD)?
Behavior Driven Development (BDD) is an agile software development process which encourages collaboration between the customer and the development team. In this context, the development team is referred to as the Business Analysts, Software Engineers, Quality Assurance Engineers, and User Interface/User Experience Engineers. This approach helps all parties understand how the software needs to be developed based on users’ behavior within the system. It helps the team understand how this feature is valued by the end user. BDD derives from Test Driven Development (TDD), a development process in which test cases are written before implementation.
BDD for User Story Writing
The BDD approach can be used for user story writing. A user story consists of a user story narrative and user acceptance criteria. Both help reduce the requirement-build gap between the business and technical users. One of the industry-recognized best practices in writing acceptance criteria is the Behavior-Driven Development (BDD) format. This format usually has two sections:
- User Story Narrative – This is where the purpose and the value of the feature are explained.
- User Acceptance Criteria – This is where the scenarios of a feature are explained.
The structure is as follows:
User Story Narrative
As a: <role>
Action: <Goal for the User Story/Feature>
So that: <Reason for the User Story/Benefit>
User Acceptance Criteria
Persona: <user role>
Given: <pre-condition>
When: <action>
Then: <Expected outcome>
Notes: <Additional notes, diagrams or tables which may be added to further enhance the understanding of the requirement>
NOTE: If several loops of Given, When, and Then conditions must be used to complete the story, add them, as necessary. Add as many acceptance criteria as needed.
Figure 1 – Sample User Story Template
Is it worth following a BDD Approach for User Story Writing?
There are several advantages of using the BDD approach for user story writing and some of them are as follows:
- Improved team collaboration: The user stories explain the requirement in a non-technical language and cover all the user criteria that should be met when delivering the feature. Hence, the development team can refer to it to understand the full picture of the requirement and it helps to minimize assumptions and back and forth communication between all parties.
- Gives a 360-degree view: The acceptance criteria should be written to capture all user scenarios, and this helps the team think through the problem and present the best possible solution that can cover all these scenarios.
- Guide for testing: These stories can be used as a guide by Quality Assurance Engineers when producing test scenarios and test cases. This practice will result in producing higher quality code with less defects.
- Help Requirement Validation: As the user stories and acceptance criteria are written from the user’s point of view, it is easier to get them validated with the end user.
There is no “silver bullet” that addresses all the challenges to productive software development. Every solution has at least one downside when putting them into action. Some of the challenges that comes with this approach are as follows:
- User Story breakdown can be hard: If the feature is complex and large, it is advisable to break it into several user stories. However, this can be quite challenging, especially if you are new to the BDD approach.
- Technical details are not included: User stories do not mention how the software needs to be built. A developer referring to a user story may not fully understand how to proceed with the implementation without having the technical details in place. This piece of information needs to be given to the developer via a different mechanism.
- Not keen on documentation: Due to the typical human behavior, developers are not very keen on reading requirement documentation.
Some tips to help you get On Board with BDD
- Use the BDD approach of user story writing for requirement gathering so that you know what questions to ask.
- Avoid referring to UI (User Interface) elements in the acceptance criteria. This should only explain the requirement and not the solution.
Given that I have registered as a user, when I select the items I need from the dropdown, I shall be able to view the “Order” button.
Given that I have registered as a user, when I select the items I need, I shall be able to place my order.
- Keep the descriptions as short as possible, to avoid confusion and to encourage the users to read the acceptance criteria.
- Avoid adding any technical details to the acceptance criteria.
Final Thoughts
Each team, even within the same organization, may not always follow the same processes in general work practices. So, it is quite understandable if the same approach for requirement documentation cannot be followed by all. However, it is advised to create a template for user stories so that uniformity is maintained within the team, and it can be used as a guideline to proceed with the requirement modelling.
Use this as a guide to start using BDD approach in your user story writing and share your thoughts in the comments below.
Want to join #TeamPurple?
Apply via Careers | IFS today!
Do you have questions or comments?
We’d love to hear them so please leave us a message below.
