Behavior-Driven Development (BDD) is a collaborative and disciplined technique that companies can use to build the right product. In the last decade, BDD has had its share of glory and criticism. While many teams in the recent past have reaped benefits from this technical practice, some teams complain they are yet to see any value from using BDD. This article aims to address this rift by answering three questions:
- What is BDD?
- What are the ideal conditions for using BDD?
- What are some ways to measure complexity in the problem and solution spaces?
What is Behavior-Driven Development (BDD)?
Behavior-driven development has been a buzzword in recent years and many teams are adopting it. At the core of BDD is collaboration between the development and business orgs, which enables teams to build the right product. As a side effect, BDD helps you to create an automated acceptance-test suite.
BDD builds on test-driven development (TDD) and extrapolates the principles of the latter for use beyond strictly developing software. For example, whereas TDD starts with test code during software development, BDD starts with a desired user behavior. BDD also expands the all-too-familiar user story (“as a… I want… so that…”) to include scenarios that then serve as the acceptance criteria for a “passed BDD test” (i.e., successfully executed behavior). Even the wording stays the same (example from Wikipedia):
Team members work together to identify these different scenarios. High-performing teams use working agreements to commit to only pull in work on features in which user scenarios have been well defined. Because these scenarios define the acceptance criteria for the feature, the scenario identification process involves full team participation. In these meetings, it’s essential that the entire development team, QA engineers and Product Owner – sometimes referred to collectively as “the three amigos” – participate, to ensure all perspectives are considered. Along with the three amigos, any other members who can constructively contribute to scenario identification are also welcome to participate.
During these interactions, dev team members get a better understanding of the business and vice versa. It has also been observed that identifying and discussing scenarios helps the team analyze and study the feature in detail. Many teams benefit from this practice as it helps them shape their product.
When is it Ideal to Use BDD?
Any product that we build exists somewhere in the solution space, whether it is mock-ups, wireframes, prototypes or the actual product. The solution space is where we focus on the answers to any given problem. Typically engineers, developers, quality assurance, operations, etc., are more concerned with devising a solution to a predefined problem. Conversely, the problem space – where the focus is instead on the problem itself – is more abstract or vague; it could just be a thought or idea like, “How to help farmers.” This is the space where the customer’s wants, needs, and pain points reside. It is also home to our Product Owner. If we identify the right problem and marry it with the ideal solution(s), we have a better chance of producing an outstanding product. This is what some call “building the right thing” (problem space) and “building the thing right” (solution space).
But, as we see in this figure, there tends to be a gap between the mindsets of the problem-definers and the problem-solvers.
Mind The Gap
The above figure depicts the problem space and solution space in typical software development teams. The problem and solutions space are disjoined and there is a gap between the mindsets of people who live either in the product and solution spaces. For example, as developers, we are more comfortable thinking about the code that will realize the requirements, rather than the requirements themselves. Hence, as developers, our thought process is more skewed toward the solution space. Similarly, a product designer or Product Owner might not be aware of the technical complexity of a requirement that might look simple and innocent. They are too focused on the problem, not its implementation.
But that’s not all: not all problems and solutions require the same level of work.
The problem and solution spaces each have its own complexity. Complexity is very much related to the team’s area of expertise and the product that they are developing, hence it’s very context-dependent. If each of the spaces can be either LOW or HIGH, we can classify different product development scenarios into four categories: LOW P – LOW S, LOW P – HIGH S, HIGH P – LOW S, HIGH P – HIGH S. Here are an example of each:
- Problem (LOW), Solution (LOW) – We want to build a simple shopping cart application and the designated dev team has adequate expertise in building e-commerce applications.
- Problem (LOW), Solution (HIGH) – We want to build a simple shopping cart application, but the designated dev team does NOT have adequate expertise in building e-commerce applications.
- Problem (HIGH), Solution (LOW) – The business does not have the right connection with customers or an understanding of their needs and wants, but the desired product could be easily developed by the designated development team.
- Problem (HIGH), Solution (HIGH) – The business wants to develop an MRI clinical application suite for radiologists. Here the problem space requires an understanding of medical terminology, how radiologists work with these applications, etc. Meanwhile, the solutions space is also complex, meaning that the team might need to invent novel concepts to analyze and visualize the data.
In the above examples, we treat complexity as an attribute associated with the entire product but the fact is that the complexity of the individual problem and solution spaces often differs for each story or requirement. When we say that the problem space of a product is complex, we assume most of the requirements are complex in the problem space. In most cases, one would get a big picture of the complexity levels of the product by analyzing the stories that make up the Minimum Viable Product (MVP).
To BDD or Not to BDD?
BDD works well when the problem space is complex. This is because BDD’s disciplined approach, which relies heavily on collaboration between stakeholders residing in either the problem or solution space, helps to bridge the gap between the two. During the scenario refinement process, the developers get to know exactly what they need to build (“build the right thing”). Then it becomes a matter of quality and capability: does the dev team have the necessary skills and tools to build high-quality products and services (“build the thing right”)? If so, they can use BDD (and perhaps even TDD) to succeed with flying colors.
When both the problem and solution are complex, BDD helps enables shared understanding, which in turn makes the life of people in the solution space much easier and they can start the other half of implementing the solution in the right way.
Teams whose problem space is simple can continue to document scenarios and automate acceptance testing, but they need not spend too much time and effort discussing and debating scenarios. Either the developer, tester or Product Owner can come up with scenarios, which the team reviews and can start development on. The problem space being simple, it is expected that everyone understands the problem pretty well and there is less scope for confusion and doubt.
One thing to be noted is that just documenting a few scenarios and automating it as the test is not BDD. If you don’t spend quality time to have the right conversations between the people of either space and capture these scenarios in the user story, BDD is not complete. This means that you need full team participation in these discussions. If you are using a lot of energy and resources to make BDD work when the problem space is simple, BDD can be an overkill. This may be why some teams complain that they don’t see any real value in adopting it.
How to Measure Complexity
If high complexity of the problem space is the motivator for using BDD, how do you measure problem space complexity? The answer is: it’s difficult. There could be cases where the problem looks simple due to the second order of ignorance (i.e., when you don’t know what you don’t know). For teams starting to practice BDD, an inspect-and-adapt approach would be the right way toward understanding and taming the complexity beast. That means that teams will have to make mistakes and learn from them. Another approximate and yet effective way of estimating complexity is to use the 5-point scale that Liz Keogh proposed in her blog Estimating Complexity:
- Just about everyone in the world has done this
- Lots of people have done this, including someone on our team.
- Someone in our company has done this, or we have access to expertise
- Someone in the world did this, but not in our organization (and probably at a competitor)
- Nobody in the world has ever done this before
One can reap greater benefits and better ROI with BDD if the problem space complexity is greater than 2.
For a successful product development, it is crucial to bridge the gap between what users want and how to create a product or service that delivers to users what they want. We can think of former as residing in the problem space and the latter residing in the solution space. These each have their own set of complexities which are context-dependent. Unfortunately, there is often a disconnect between stakeholders who live and operate in the problem space (e.g., product managers, Product Owners, designers) and the development teams tasked with delivering a solution.
Behavior-Driven Development can be an effective approach to product/service development if the problem space is complex because it bridges the gap between the problem and solution spaces. BDD relies heavily on collaboration between “the three amigos”: business stakeholders, the entire development team, and QA. It also uses human language to construct clear acceptance criteria in the form of user behavior scenarios. BDD doesn’t tend to yield as much value when the problem space is simple, which may be why some teams using BDD don’t see value.