What is behaviour driven development?

HS-Blue-BG.png

 Have you ever stood in a sprint demonstration where the product owner said:
“That’s not what I wanted” ?

 
Hindsight Vertical Arrows.png
 
 Video screenshot

This is a common problem in software projects – one of the biggest sources of bugs and rework – and usually highlights a lack of team understanding around requirements. Behaviour driven development (BDD) is a software development technique for agile teams that helps to reduce this type of rework and regain time for new development work.

When applied correctly, BDD helps to solve the “That’s not what I wanted” problem by building a shared understanding of the user story between the product owner, developers and testers.

This leads to a significant reduction in the amount of time spent on rework caused by misunderstood requirements, enabling teams to deliver the right thing, first time.

 

Teams with poor communication and collaboration techniques are more likely to produce features that don’t match the business vision or that contain bugs. One of the most common causes of bugs and delays in software projects is a lack of shared understanding of the user requirements between product owners, developers and testers - accounting for 54% of defects in delivered software. Preventing Requirement Defects, S Lauesen & O Vinter

 

Consider BDD as a process of three stages:

 
 1

Discovery

BDD involves talking about your domain from the user’s perspective, to ensure you are building the right thing. An informal meeting commonly known as ‘three amigos’ brings together team members from testing, development, design and the business, to have a conversation.

They collaboratively discuss examples of how they expect the software to behave in different situations, with everyone asking questions to dispel any incorrect assumptions and reveal new information. Once everyone is clear about what is required, then shared understanding has been reached. This collaborative phase is the single most important part of BDD.

 
 2

Capture

Team members may jot down notes during their collaborative sessions and then, either during or after, they can capture the key examples from the discussion that illustrate the behaviours to be delivered. In BDD, this is written using Gherkin syntax which consists of ‘Given When Then’ statements. The captured examples help teams to agree behaviour before development work begins.

 
 3

Automation

Once the key examples have been captured and the team has agreed they are ready, developers can then begin to use them as automated acceptance tests to guide the development, using a process known as ‘outside-in development’.

This encompasses ATDD (using automated examples to guide us towards building the right thing) and TDD (using unit tests to guide us towards building it right). Once all the acceptance tests are passing, this gives the developer confidence that what the business wanted has been delivered, thus reducing the probability of rework and leaving more time for new development work.

Many people mistakenly associate BDD purely with test automation, but it is more than that.

 

“Having the conversation is more important than capturing the conversation is more important than automating the conversation.” Liz Keogh

 

How does BDD benefit different members of the agile team?

Hindsight Product Owner.png

BDD for product owners

As a product owner you’re the one responsible for the success of the product and, for you, software development is all about the user. You don’t want to see the code; you want to see that the software works for the user in the way you intended.

 
Hindsight Developer.png

BDD for developers

As a developer you want to confidently build what the business has asked for. You’d like to spend less time on rework and have more time for new development work.

 
Hindsight Tester.png

BDD for testers

As a tester, you want to confidently run user acceptance testing and prove the software works in the way the business intended. You’d like to spend less time on back-and-forth bug testing at the end of the project when a deadline is fast approaching.

 

How does everyone interpret user stories? It’s a subjective thing and sometimes we make assumptions… Get a sense of how easy it can be to misinterpret requirements by taking our 10-minute BDD challenge with a co-worker.

 
 
Hindsight Vertical Arrows.png
 

Ready to take the next step on your BDD journey?