5 Tips for Successfully Implementing Behavior-Driven Development in Your Team

Have you ever been part of a team where tickets are hard to understand or don’t supply enough detail for the team to properly work? Experiences like these make many developers think about using Behavior-Driven Development (BDD). BDD emphasizes collaboration between developers, testers, and stakeholders to define and deliver software that meets business requirements. Some expected benefits of BDD include:

• Improving collaboration to build a shared understanding of the problem to be solved.
• Providing documentation that is easy to understand for all stakeholders and can be automatically checked against the system’s behaviors.
• Increasing test coverage and earlier detection of defects by creating automated tests based on the defined scenarios.
• Increasing feedback and the delivery of value by working in rapid, small iterations.

At first glance, BDD appears to be straightforward. It enhances your existing Agile approach, synthesizing Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD). You start by defining the desired behavior of the software in terms of concrete examples or scenarios that describe the behavior of the system in a clear, concise way. 

In practice, however, BDD requires a significant shift in philosophy that involves the entire development organization. If you’re considering implementing BDD, here are some tips to help you get started.

1. Know your team members

You work with your team every day and know them well. With BDD, it’s important to carefully consider the expertise, as well as the gaps in knowledge, of each member individually. For each team member, ask:

• Are they familiar with BDD or TDD? 
• Are they familiar with the language and technology you are planning to use? 

Asking these questions will help you define the documentation you’ll need to write and the knowledge transfer and training you need to put in place before implementing BDD.

2. Consider the team structure

How your team is structured and your projects staffed can impact how you implement BDD. Do you have Agile-certified team members and technical leads? Does your team include both QA and developers, or is it a matrixed team made up of members from different departments? IIs your team allowed to make independent decisions?

If you are outsourcing development to a partner like Gorilla Logic, consider the staffing model that best fits your BDD requirements. Having a complete nearshore team gives you the most freedom so that you can coordinate with your team, establish knowledge transfer and training sessions, identify a candidate project, and identify and implement the technology. On the other hand, using a staff augmentation approach can make BDD implementation more complex, requiring you to coordinate communication and collaboration across many more teams and stakeholders.

3. Get buy-in from all the stakeholders

Implementing BDD is an intensive process with significant impact on resources and budgets. You’ll need to build a business case to get buy-in from all the stakeholders involved. A Director of Engineering, for example, isn’t likely to change the development methodology without understanding the business case. They’ll want to fully understand how it impacts individual team members and their productivity, including how much time and effort might be required for training and implementation. They’ll need to work with Product Owners to adapt how business requirements are interpreted. All this translates to an investment of time and money that must be justified.

You can start the process of getting stakeholder buy-in by documenting your business case, including these key topics:

Articulate the problem being solved, and why it should be solved

How much time does your team spend trying to understand tickets that are incomplete or poorly defined? How much time is wasted when poorly written tickets are worked on and the resulting work isn’t what was needed? What is the impact to the business when there is a gap between the product requirements and the actual implementation of a feature? What is the cost in time and resources when a defect is discovered in acceptance testing that should have been resolved during planning?

Define the scope

Identify which teams you plan to  involve in the BDD implementation and which projects are you planning to include. Sometimes there are legacy apps or pre-existing projects with functional test suites that are working well and can be excluded from your BDD initiative.

Identify the stakeholders

List all the roles that will be part of the BDD implementation. At a minimum, your stakeholders are likely to include: technical leads, QA leads, Product Owners, Scrum Masters, developers, QA engineers. 

Propose the solution

Prepare a Proof-of-Concept (POC) describing how you are planning to use BDD. Identify the tools  and frameworks, such as Cucumber (Ruby), Specflow (.Net), or Behave (Python). Identify the IDE extensions and ticket management system, as well as any other tool you expect to need.

Estimate the cost impact

BDD implementation costs include:

• Education: Individual team members may need training that incurs both cost and time investment.
• Testing automation infrastructure: If you don’t have one in place, you may incur costs in building the appropriate testing automation infrastructure. 
• BDD tools: Most BDD tools are free, but it’s important to know that you can practice BDD without any specialized BDD tools. You will need to evaluate the possible benefits of any BDD tools, as well as any associated implementation, training, and maintenance costs.
• More intensive stakeholder involvement:  BDD challenges stakeholders with in-depth questions about their requirements. The overhead of more frequent and deeper conversations across teams can add up, and the impact of the time spent should be understood.

Map out the implementation plan 

Define a plan to transform your proposal into reality, consider having knowledge transfer and training sessions with the affected team members, and identify a candidate as a start-up point, it can be a project/service/feature that will help the whole team to be prepared upfront.

Define how you will measure success and ROI

One of the most substantial benefits of BDD is in reducing the number of defects or bugs found during acceptance testing. BDD transforms business requirements into living documentation that saves manual testing time and diminishes the context switch cost. 

Collect statistics of bugs and defects rates and compare them with the final numbers of your first candidate project. Also, do a retrospective after each project, and depute periodically.

Explain how BDD will complement the existing development life cycle

Identify where BDD can be implemented. Is there any legacy code? Are there other functional test suites already in place and integrated in the team/company standard process? It’s important to document the existing workflow and identify where you will introduce additional steps to adopt BDD. 

The less intrusive approach is to use existing meetings and steps as part of BDD preparation. For example, you can use drafting/grooming meetings to depute all the Gherkins; the team is already assembled to discuss scenarios and technical details so use this time to improve them and make them part of BDD suite upfront. 

For the development time required, you can propose that an initial new task/ticket be created to do the BDD suite code for each feature; this work item will timebox the effort and will allow the team to measure the time/cost required.

4. Ensure knowledge transfer and training

As part of the onboarding process for BDD, it’s important to set up meetings to help the team understand the approach, the technology, and how it will all be implemented. Here’s a recommended series of meetings and documentation to help guide your team:

• BDD basics and concepts: 
  • What’s TDD? What’s BDD? 
  • Which tools are we using? 
  • Share a demo of all the tools and processes, using your team’s programming language.
• Writing Gherkins for BDD, for the people who create feature descriptions and scenarios, aimed at helping avoid misunderstandings between developers and the product/business:
  • Gherkin syntax: When to use Given, When, or Then keywords
  • How to use data tables, scenario outlines, and scenario backgrounds
  • See this blog post for more useful tips on writing Gherkins. 
• Wikis and documents: 
  • Expose all the knowledge necessary and make it accessible to everyone who might need to find a concept or how to use a tool related to BDD.

5. Be flexible

As with all Agile development, you will find steps where you need to adapt to the team process and capabilities. Depending on your team’s planning strategy, you might find that tickets are thoroughly reviewed and discussed, and scenarios can be quickly moved to the BDD suite. 

But sometimes, Gherkins cannot be depured or you may find they can be improved to avoid duplicity.  If that’s the case, it’s fine to have an intermediate conversion from the ticket to the BDD suite. Once done, share the scenarios with the team. You’ll likely find that next time, things run a bit more smoothly.

Remember that sometimes product or business team members might not have a technical background; they could be handling the product owner role because they are the experts in the company and you need to help them through the process.

Remember that BDD implementation is a journey

Implementing BDD is a process that could take months and even years to complete. Treat every step as progress; every scenario corrected, every understandable ticket, and every bug avoided is a win. In the end, you will have the satisfaction of having improved the interaction of your team, the quality of your solutions, and the speed of your delivery.