As our team at MozaicLabs is growing, we felt the need to improve the way we define and communicate features entering the development phase. As new developers joined the team, it was clear that we needed a better process. The Product Owner had more analysis and testing work on her hands. The new developers needed a way to easily understand what they were building and gradually get acquainted with the product as whole.

BDD is helping us a lot. In the belief that other teams will benefit too, here’s how it works for us, as well as some mistakes we’ve made along the way.

What is BDD – quick recap

BDD (Behaviour Driven Development) emerged from TDD (Test Driven Development), in an effort to clarify the concept and bring test writing closer to human language. It was further developed into a common language between the business and technical people.

“If we could develop a consistent vocabulary for analysts, testers, developers, and the business, then we would be well on the way to eliminating some of the ambiguity and miscommunication that occur when technical people talk to business people.” – here’s Dan North’s full article introducing BDD.

BDD offers a simple framework for defining user scenarios corresponding to each user story:
Given some initial context,
When an event occurs,
Then ensure some outcomes.

BDD is a process meant to improve communication between team members, support clarity and minimise hand-overs. If you only use BDD as a method to move specifications from the Product Owner to the Developer, you’re missing out on its most powerful benefits. Involve as many people as necessary in the BDD scenario definition phase. You can involve roles like Product Owner, Developer, Tester, Business Analyst, UX Designer.

How to write BDD scenarios

Rule of thumb: start with the outputs

Then:
When you begin analysing a feature idea, start by thinking of real life examples of how the user would use the feature. Ask “What if…” and come up with alternative ideas of how the feature might be used. Decide how your product should behave in each of these cases. Define your product’s output for each case. This will give you the scenarios and the Then’s in the BDD Given-When-Then framework.

When:
For each alternative usage you’ve defined (scenario), think of the actions that have to be made on the system, to create the desired outputs. These will be your When‘s.

Given:
Define the possible entries that would generate each output. These are your Given‘s.

Capture the defined scenarios and share with the team. Although this is a very useful step, don’t treat this as the goal of your meeting. The main goal is the conversation you have around all the scenarios and the shared understanding that’s been built between the team members.

A real-life BDD example

Here’s the process our team goes through, from the moment a user story reaches the Analysis stage, to the moment it reaches the production environment.

The Product Owner starts the analysis by creating the BDD scenarios. Here’s an example outcome of our analysis.

 

Usually, the PO will review the scenarios with one other team member who understands both the technical & user value side – in our case, that’s the CTO.

When the developer starts work on the feature, she will go through the scenarios and have a quick conversation with the product owner to:

• clarify the scenarios
• discuss any cases that were missed from the analysis and update scenarios
• make sure she has all the resources needed

If anything new comes into light while developing (new cases, questions etc.), the developer discusses with the Product Owner on the spot. If there’s any work needed from the PO at that point, this gets high priority and is done by the PO asap.

Because we don’t have, by design, a dedicated tester in our team (if we did, she’d be involved all the way in the process, starting with the BDD scenarios definition), once the user story is developed and pushed to the testing environment, the Product Owner tests the functionality. She follows the BDD scenarios which are also used in this case as acceptance criteria. When everything is ok (feedback is integrated, possible bugs are solved) the PO gives the go to push to production.

Here are some benefits we find in BDD

• Determines a thorough feature analysis
• Acts as a valuable conversation support between the developer and the Product Owner
• Helps the team clarify requirements, discover new use-cases and make just-in-time decisions
• Clarifies the way the developed features will be accepted and pushed to production
• Supports the developer to work with confidence and keep continuous focus
• Sustains faster & more predictable delivery of features

Red flags from our experience

• Skipping the conversation

We’re human. We went “the fast way” and skipped the product owner – developer conversation. This resulted in missed use-cases that had to be treated after the development began, thus wasted time back-and-forth between the PO and dev… and “bad requirements” jokes.

Advice: don’t do it.

• Too many outcomes

We didn’t separate outcomes thoroughly. Which basically meant we treated more user stories as one. This got us bigger cycle time, more than a bit of confusion on the development side trying to solve too many things at once, and a few come-backs from testing to developing.

Advice: don’t waste the chance to discover your story isn’t sliced enough.

• Build just in time

As a Product Owner, it’s easy to get carried away analysing too many features. You dedicate a wider timeframe to doing “BDD work” and fill up a substantial “Read for dev” buffer. The problem with this approach is that you’ll have to think everything all over again if you’ll have the discussion with the developer after a week.

Advice: having an analysed feature buffer is good, but keep it short – according to your number of developers & cycle time.

• You’ll still miss things

Sometimes back and forth will still happen. Don’t expect extraterrestrial analysis skills from anyone in the team – you know YOU’re human, right?! When less than ideal situations occur, communicate fast and don’t assign blame.

Advice: collaborate to quickly find the answer and everyone will be happy.

BDD was a valuable addition to our process, and if you’re not using it already, we encourage you to try it out. If you’re doing BDD in your team, it would be great to learn about how you’re including it in your daily activities and your personal learnings around it, so please join the conversation in the comments below.