What Is Behavior-Driven Development?

Scrum teams that build software often have their own technical jargon that can be really difficult for outsiders to understand. When your team applies behavior-driven development (BDD) practices, you can bridge the gap between the technical team and business stakeholders by referencing work in a way that everyone can comprehend. When development is done this way, everyone can be on the same page about what's needed from the product.

This practice follows three key principles that are complementary to agile principles:

1. Focus on the behavior and outputs you want.
2. Stakeholder and developer collaboration.
3. Approachable, clear, and transparent communication.

How Does Behavior-Driven Development Work?

BDD is a method that supports the collaboration between technical and non-technical stakeholders.

To work this way, the following steps are taken by the scrum team:

• Apply the "Five Whys" when crafting product backlog items to connect its purpose to business goals.
• Focus on work that contributes to those business outcomes and avoid wasteful, unnecessary work that doesn't get you closer to those goals.
• Describe behaviors in simple sentences that are easily accessible to the team and business stakeholders in order to improve communication.

Behavior-driven development is an offshoot of the earlier practice of test-driven development (TDD). While TDD is great at writing tests before developing code as a way to save time, the tests were often still written in technical ways that were difficult for people outside of the technical team members to understand. 

With BDD, the focus is on clear communication and outcomes of the product rather than the technical solution, which allows everyone to create products from a more customer-centric point of view. It also makes it easier for the scrum team and stakeholders to work collaboratively, which is something that is key to agile ways of working.

Examples of Agile Behavior-Driven Development

When getting started with BDD, you'll want to think of "scenarios" rather than "tests." Rather than refer to "function tests," you'll use "specifications of the product's behavior."

Behavior-driven development scenarios are pretty simple to write with a little practice. There are just three scenarios that you need to be thinking about:

Given > When > Then

Here's an example of BDD for creating a Facebook account:

User Story: As a middle-aged mom, I want to create a Facebook account so that I can share pictures of my kids.

• GIVEN Jane is on the Facebook registration page
• WHEN she enters all required registration fields
• THEN a Facebook account is created

Benefits and Drawbacks of Behavior-Driven Development

A major benefit of BDD is that it puts in place a method for ensuring that clear communication and collaboration between the technical team members and everyone else involved with the product have a clear understanding of the desired behavior of the product.

The commonly understood language of given-when-then makes it much easier for everyone to relate to than other development practices that are difficult for non-developers to recognize and interpret.

Since teams are often required to create end-user documentation when delivering a software product, the BDD scenarios can be used to begin that process, saving a lot of time at the end of a project.

This approach is all about the outcomes of the product, so it helps alleviate the development team from developing unnecessary bells and whistles in the software and keeps everyone focused on the key benefits that customers are looking for, allowing development to happen at a faster pace.

One drawback with any new process is that there's a learning curve for the team, which could cause them to slow down before they speed up. Additionally, if the team isn't yet familiar with TDD, it's difficult to start with BDD as a first step.

Since BDD is a conceptual approach, it doesn't require any specific software tools. However, for software developers that aren't used to working with behaviors and are used to relying on a software tool, getting this approach to happen naturally will take some time and effort.

Try BDD on Your Team

The practice of BDD can greatly improve communication between the software developers and the rest of the team and its stakeholders. This practice uses common language that focuses on customer behaviors with the software and the outcomes it's meant to produce. It's a great practice that helps to build agile ways of working on a software development team.

Interested in building your scrum skills for agile engineering environments? Dive in and earn an in-demand certification from Scrum Alliance to showcase your agile developer capabilities with Certified Scrum Developer® (CSD®).

Learn about CSD