Smarter ideas worth writing about.

Behavior Driven Development - Part I

As Agile practitioners we spend a lot of time talking about the intangible aspects of Agile, and rightfully so, since much of the value is dependent upon modifying our mindset and attitudes.  But there is also value to adding some structures and practices, particularly when we can leverage them to work more efficiently.  This post proposes to show how the practice of Behavior Driven Development (BDD) can be used to enhance agility.

So what is Behavior Driven Development?  And how is that different from Test Driven Development (TDD)?  Understanding TDD is probably a good place to start. Many of us have at least heard of TDD.  At a high level it can probably be best understood as a software development process that is premised on a developer writing an (initially) failing test case that defines an improvement or new function and then produces a minimum amount of code to pass that test.

The aim of TDD is to shift the mindset of a developer to create small, discrete units of code that will provide value as defined in the requirements.  This practice requires developers, testers and domain experts to work more synchronously in order to be efficient.  The expected output is higher quality code and a repeatable collection of well-vetted test cases.  From an Agile perspective, TDD can support continuous integration, is a great complement to paired programming, and keeps a sharp focus on team collaboration.

TDD provides a framework for developers to translate requirements into testable units of code.  However, there is still a layer of abstraction that can add clarity by addressing why the system should behave in a certain way.  Enter BDD.

It may be helpful to think of BDD as an evolutionary step past TDD.  The underlying value of TDD is preserved because there is still a focus on tight alignment of coding, testing and design.  But in addition, BDD refines the focus of the test to deliver those behaviors most closely aligned with a business objective.  How?  By using the following principles:

  • Apply rigorous analysis to ensure each user story is clearly related to business objectives
  • Minimize waste by only implementing behaviors that contribute most directly to business outcomes
  • Apply the previous bullet points to the lowest levels of abstraction so the cost of iterating and evolving remains low
  • Describe behaviors in a single notation which is accessible to developers, testers and domain experts to create solid and tangible basis for team communication. 

The value of focusing on behaviors that satisfy business objectives is fairly obvious; it ensures that the team is working on the right things.  It also allows the team to quickly validate if the desired results have been achieved and permits quick adaptation without prolonged analysis.  

But there are some additional tangential benefits of adopting BDD practices that also promote agility through language. 

  • Using more commonly understood language in notations helps to demystify code and can remove some esoteric knowledge requirements.
  • Common language enables developers, testers and domain experts to communicate more clearly by reducing “translation” problems. 
  • Using more common ubiquitous language decreases the need for more formal technical and end user documentation because it is more accessible.

The importance of that last bullet point cannot be understated.  The use of common language built-in to the product decreases the necessity for mapping documents and other technical reference overhead.  In fact, it could be argued that adopting that new language convention is the most critical component of BDD.  Coming up in our next installment, we will discuss how that new language convention affects acceptance criteria and executable specifications.


About The Author

Project Services

Juan Flores, Dave Wanner and Sarah Williams, members of Cardinal's Project Services practice, contributed to this blog.  To contact them for further conversation please email, or