Behaviour Driven Development (BDD) is a collaborative and disciplined technique to help us build the right product. In the last decade BDD has had her own bit of glory and criticism. Many teams in the recent past have reaped benefits from this technical practice, while some teams complain that are yet to find any value. This article focuses on answering two questions; Why BDD might not always be the right choice? What are the ideal conditions when teams should adopt it?
Behaviour driven development  has been a buzz word in the recent years and many teams are adopting it. The core of BDD is the collaboration angle that enables teams to build the right product. As a side effect BDD gives you a very essential output, which is an automated acceptance test suite. BDD team members work together in identifying different scenarios elaborated in the form of examples. High performing teams ensure through working agreements to only pull those features in which scenarios are well defined. These scenarios define the acceptance criteria of the feature. The scenario identification process involves full team participation and in these meeting its essential that the three amigos i.e. the entire development team, QA engineers and product owner should participate. Along with the three amigos any other members who can constructively contribute in scenario identification are also welcomed.
During these interactions technology facing members get a better understanding of business and vice-versa. It has also been observed that identifying and discussing scenarios helps the team in analysing and studying the feature in much detail. Many teams benefit from this practice as it helps them shape their product , saying so few teams are yet to find value in investing time and effort towards these meetings and ceremonies . One should keep in mind that for BDD to be effective we require full team participation.
In this article I am making an assumption that these teams who are not finding much value in adopting BDD, were practicing it in fullest of its spirits and not just documenting scenarios for creating an automated test suite. This article doesn’t discuss on how to effectively practice BDD, as it’s out of scope. This article will throw some light on why BDD might not always be the best fit for all type of product development.
Problem Space and Solution Space
Before we go further I want to share a high-level concept of problem space and solution space . I have been studying this concept for few years and have always loved to co-relate BDD with this concept for better understanding.
Any product that we build exists in solution space whether it is mock-ups, wireframes, prototypes or the actual product. Typically Engineers, Developers, Quality Assurance, Operations etc. loves to reside in this space and their thinking is skewed towards the solution. Whereas problem space is more abstract, vague or could just be a thought or idea like, “How to help farmers”. This is the space where the customer’s wants, needs, pain points reside. It is also home for our Product owner. If we identify the right problem space and marry it with the ideal solutions space, we have a blockbuster product.
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 mind-sets of people who live in product and solutions spaces. For example as developers we are more comfortable to think about the code that will realize the requirement than the requirement itself. Hence as developers our thought process is more skewed towards solution space. Similarly a product designer or product owner might not be aware about the technical complexity of a particular requirement that might look simple and innocent.
Since we got a feel of these two spaces we should also know that each of these spaces has its own complexity. For example if we want to build a simple shopping cart application and we approach a team whose expertise was building e-commerce applications, building this product might be simple for them. In the above example both the problem and solution space complexity was less. Complexity is very much related to the team’s area of expertise and the product that they are developing, hence its very context dependent. For example if we give the same task of developing a simple shopping cart application to a team who is only developed embedded software , the product development could be a bit challenging for them . An example for problem space being simple and solution space been complex could be developing a product that automatically identifies objects (e.g. car, phone, monkey, money) in an image. Similarly teams developing a MRI clinical application suite for radiologist might find both the solution and problem spaces complicated because understanding the problem might require understanding medical terminology, how radiologist works with these applications etc. The solutions space is also complex meaning that the team might need to invent novel concepts to analyse and visualize the data.
In our above discussions we always considered complexity as an attribute associated to the entire product but the fact is that each story or requirement has its own problem space and solution space complexity. When we say that the problem space of a product is complex we assume most of the requirements are complex in problem space. In most of the cases one would get a big picture about the complexity levels of the product by analysing the stories that make up the minimum viable product.
When to use Behaviour Driven Development
BDD works pretty well when the problem space is complex. This is because BDD’s disciplined approach enables collaboration with the stake holders residing in either of the spaces which help in reducing this gap which we discussed above. Teams who had adopted BDD often comes with flying colours if their problem space was complex and solution space was simple , this is because during the scenario refinement process the developers get to know what exactly the need to build and they know how to build it the right way. In case when both are complex BDD helps in narrowing the gap, 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 getting to the solution right. In such situations when both the spaces are complex BDD will only help in defining the problem. The success of the product also depend how engineering teams come up with the right solution. Kindly note “BDD doesn’t come with brains, we have to use ours”.
Below is the BDD adoption matrix. We can see that when problem space complexity is high we tend to get more benefit from adopting this practice. This doesn’t mean that there is no benefit at all in adopting BDD when problem space is simple. In all the below four cases we get the benefit of getting an automated test suite of acceptances test, but that is just the side effect of BDD. Teams whose problem space is simple can continue to document scenarios and automate acceptance testing but they need not spend elaborate time and effort towards discussing and debating scenarios. Either the developer, tester or product owner could come up with scenarios; team reviews it and start developing it without spending too much time discussing it. The problem space being simple it is expected that everyone understands the problem pretty well and there is less scope for confusions and doubts.
One thing to be noted is that just documenting few scenarios and automating it as test is not BDD. If you don’t spend quality time to have the right conversations between the people of either spaces and capture these scenarios as examples BDD is not complete. This means that you need full team participation in these discussions and to make the best of Return on Investment (ROI) spend on time and effort, it only makes sense if problem space is complex. This is why BDD can be an overkill when the problem space is simple and this is the reason why some teams complain that are yet to find any real value in adopting it.
How to Measure Complexity
How can you measure problem space complexity? Answer is, it’s difficult. There could be cases where the problem looks simple due to second order of ignorance . We say second order of ignorance exist if “when I don’t know that I don’t know something”. As teams who are starting to practice the BDD style of working, inspect and adapt would be the right way ahead in understanding and taming the complexity beast i.e. Teams will have to make mistakes and learn from them. Another approximate and still effective way of estimating complexity is to use the 5 point scale which was proposed by Liz Keogh in her blog Estimating Complexity . With respect to the below table one can reap greater benefits and better ROI embracing BDD if your problem complexity is greater than 2.
|1||Just about everyone in the world has done this|
|2||Lots of people have done this, including someone on our team.|
|3||Someone in our company has done this, or we have access to expertise|
|4||Someone in the world did this, but not in our organization (and probably at a competitor)|
|5||Nobody in the world has ever done this before|
For a successful product development it is crucial to bridge the gap between the problem space and solution space. The problem space and solution space has its own set of complexities which is context dependent. Behaviour Driven Development can be one of the effective techniques to bridge this gap especially if the problem space is complex. In case the problem space is simple it might be an over kill and teams might not find real value practicing BDD.
I hope this article has cleared some mist on when your team need to embrace BDD. Please let me know your thoughts and feedback.
 North, Dan. “INTRODUCING BDD.” Web log post. Http://dannorth.net/introducing-bdd/. Dan North Associates, 1 Mar. 2006. Web. 19 Jan. 2016.
 Olsen, Dan. The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback. John Wiley & Sons, 2015.
 Robinson, Frank. “Minimum Viable Product.” A Proven Methodology to Maximize Return on Risk. SyncDev, n.d. Web. 19 Jan. 2016.
 Evans, Eric. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional, 2004.
 Armour, Phillip G. “The five orders of ignorance.” Communications of the ACM 43.10 (2000): 17-20.
 Keogh,Liz. “Estimating Complexity.” Web log post. http://lizkeogh.com/2013/07/21/estimating-complexity/, 21 July. 2013. Web. 19 Jan. 2016.