One of the key paradigms in the work that we do is eliminating waste in an organization. Speeding up feedback loops and employing crisp communication both inside individual teams and externally are absolutely essential on the path to achieve effective collaboration.
When a team does not have a dedicated sprint planning session or it is done wrongly, it becomes one of the major reasons waist occurs.
BDD stands for Behavior Driven Development. It’s an approach used in software delivery to promote effective communication during sprint planning sessions. The idea is to describe software functionality from the end user perspective and make it a starting point for feature development. It’s noteworthy that Cucumber is the most commonly used tool for using BDD in test automation.
During BDD sessions, the team dives into “storytelling”. Using Gherkin jargon, team members use plain English keywords such as Given, When, and Then to walk a hypothetical user through the feature flow. Each of these user flows is called a Scenario and can be treated as a test case.
A user story consists of one or more scenarios that describe the behavior of the feature along with other details. These user stories essentially provide us with acceptance criteria and requirements for feature implementations.
The key point here is to have the whole team actively participating in story generation in order to achieve common understanding for each feature that is getting developed. If this is not how the team operates and requirements are simply dropped on the developers’ shoulders, it is extremely common to see the situation where the vision for the feature is greatly different between developers, testers, product owners, and business units.
Often, some members would be too shy to participate, some would use or try to use the gained authority to further fulfill their egos. Be aware of this.
Storytelling sessions spark arguments and discussions around the user interface and feature functionality between team members. During these sometimes heated sessions, members of the team discover gray areas in the requirements that needs to be further clarified by the business.
At first, teams that are getting onboarded with the BDD process show signs of doubt in this approach and try to push back. Nobody likes the change, especially when the existing process was in place for years and “worked”, but when you ask the team to really give it a try after an hour or so they start to discover those grey areas we’ve talked about previously. The realization arises that without this sprint planning format, certain questions would never be asked in the old model and would lead to time wasting during feature implementation or even worse, during a testing phase or a demo. A tester would come to a developer asking, “Are you sure this is how it should work?” The developer might respond, “I don’t know. I’ve developed based on my interpretation of the requirements”. And the argument begins. Too bad it would happen after the feature is already implemented and not before.
This is where the “Three Amigos” approach would shine. The idea is that during story generation in sprint planning, team members that represent different roles, such as developers and testers, would come together to further update the story’s description and create subtasks needed to accomplish the whole piece.
As a result, the process of estimating workload and scoping the sprint commitment becomes an easy task.
Transforming an organization is not an easy task. You need to be able to sell the vision and persist when push-backs occur.
In our experience, injecting BDD as part of sprint planning initiatives bonds the team together and removes barriers between individual roles. The team starts to have a common understanding of the functionality that is getting developed. That by itself lowers the risk of delivering wrong feature implementation saving an organization time and money.