Behaviour Driven Development (BDD) for Scrum Teams
Help Scrum Teams adopt BDD in 4 steps
👋 Hello, I’m Vibhor, and welcome to the 🔒 subscriber-only edition 🔒 of my newsletter, the “Winning Strategy.” Every week, I answer one reader question about Agile Products / Processes, Role-based Skills, and anything else that you need answered about your Career Growth. You can send me your questions here.
Note: If you enjoy reading this post, please show your support by clicking the little gray heart below the title above. It would really mean a lot and help spread the word about this growing newsletter. 😍
On to this week’s question!
Q: Let me start by saying that my team is hooked to your T-Split technique. We used many ways to split user stories, including Mike Cohn’s, but we keep coming back to T-Split, which is just more simple and quick. My question for you is about using BDD in Scrum teams. In all honesty, I know what it is. I just want you to make it simpler, which I think you do the BEST!! By the way, this is my second question. My first question was not answered, but I am keeping my fingers crossed for this one.
Thanks for the question.
I do apologize for not being able to answer your first question. 😰
The only metric I use to pick a question to answer is its popularity. I have an Excel sheet with all the questions arranged in categories. Much like a prioritized product backlog, I pick the one at the top.
Having said that, I do try to answer less requested questions by replying to them via email. So rest assured, I will answer your question as soon as it appears on my list. 🙂
Okay, on to the topic for this post.
Behaviour Driven Development (BDD) for Scrum teams.
Before I dive deep into the definition and application, let me first weave a context behind the use of BDD. What problems does BDD help resolve?
The Problem
The scenario I am going to share comes from my past experience. About 9 years ago, I had the pleasure of working with a fantastic team at a renowned e-commerce company. Our objective was to develop a new feature that would enable users to personalize their shopping experience by taking into account their preferences and previous purchase history.
During a specific sprint, the team was assigned to develop a recommendation engine.
When the feature was demoed to the stakeholders, there was real excitement in the air until we realized that the recommended products were not accurate. For example, a user who frequently bought children's clothing was being suggested gardening tools, while an avid gardener was getting prompted towards buying a gaming console.
This was embarrassing!
The team diligently followed the requirements, and testers didn’t find any bugs.
So, what went wrong?
After several deep-dive sessions, we found the culprit. There was a gap between what was intended by the stakeholders and what was understood and implemented by the team.
The requirements, while seemingly clear, had nuances and expectations embedded in them that were not successfully communicated or translated into the implemented functionality. The way we thought the system should make recommendations and how stakeholders expected it to were two different narratives.
It was clear.
There was a significant misalignment between the expectations of the business and what was developed and delivered by the Scrum team. A powerful yet subtle issue that slipped through the cracks, all because of our understanding or, should I say, misunderstanding of the problem.
Now the question is,
“How do we bridge this gap between stakeholder expectations and team delivery?”
And the simple answer is by applying “Behaviour Driven Development” in our approach to developing products. It addresses the key issue of 'lost in translation' requirements by embedding the “expectations” right into the development process.
Through a language that is understandable by all stakeholders - including developers, testers, and business teams - BDD facilitates a shared understanding of the problem to be solved and, more importantly, how the proposed solutions should behave.