Have you ever stood in a sprint demonstration where the product owner said:
“That’s not what I wanted” ?
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:
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.
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.
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?
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.
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.
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.
Ready to take the next step on your BDD journey?
