Four tips to help your team REALLY do BDD

For many teams, the benefits of Behaviour Driven Development are obvious. Teams that practice BDD well see significantly lower defect rates and higher quality features. These teams tend to be more engaged and creative as well. More importantly, they stand a much higher chance of delivering the solutions the customer actually needs.

So the benefits of BDD are pretty clear.

But then so are the benefits of exercise, and we don't all do as much of that as we should either.

The truth is, when the pressure is on to deliver, it can be hard to find the time to plan and analyse, even if we know deep down that this will speed up delivery and reduce defects later on in the sprint.

So here are three quick tips that can help you embed BDD practices more effectively in your team.

Never Gherkin Without Conversin' - always start with a conversation

There are two aspects to BDD practices: collaboration and automation.

Collaboration without automation will help in the short term, but you don't get the longer term benefits of living documentation and automated regression tests.

Automation without first collaborating is expensive and potentially wasteful, though it is sometimes necessary on existing projects.

It's the 'three-amigos', not the 'BDD posse'

Collaboration is at the heart of BDD, and it's where you get the most bang for your buck when you first adopt BDD practices.

Once you get the collaborative practices embedded, automation of the acceptance criteria will be easier and more natural.

So start with the conversations.

But you don't always need the whole team discussing every single story (that's why we call requirements discovery sessions the "3-amigos" and not the "BDD-posse"). Sometimes it can be hard to get larger groups together, and this can slow things down.

So if you can't get the whole crew together, get a smaller group of two or three relevant people to discuss the requirements and tease out the executable specifications, then run them by the rest of the team separately. That works too.

But whatever you do, make sure the conversations happen.

Block time before each sprint, and stick to it!

But how do you ensure that these conversations do happen?

Great question!

One good way is to block off a morning each week before a new sprint starts to do requirements discovery sessions.

In any case, block off this time systematically, even if you don't know what you will use the time on - something will usually come up.

You can also run several discovery sessions in parallel, in the same room - it's not always efficient to have everyone talking about the same story, when smaller groups can do the heavy lifting and present the findings to the larger group later on.

The story ain't done till the scenario's run

If you decide to automate the acceptance criteria for a story, make sure you automate them within the sprint.

Non-automated acceptance criteria, that you intend to automate, are technical debt, and will slow down development and testing efforts in future sprints.

When you start BDD on an existing project, automation can take more effort to set up and to integrate into the existing code base.

This needs to be factored in to the development estimates, so don't try to automate all your acceptance criteria at once.

The important thing is to get into the habit of automating in the same sprint as development, not afterwards. Start with the acceptance criteria for one story, Then, in the next sprint, do two. And so on.

But, even if you don't automate the acceptance criteria, you should still write the feature files (if you are using Cucumber) and flag the scenarios as being manually tested for now. Don't consider a story "done" until the feature files are written and the scenarios that you select to automate have been automated.

If you want to explore some techniques to get clarity around those requirements, take a look at the "BDD from Start To Finish" free training - it shows many of these techniques in their context as part of a full BDD development process.

And if you want to go more in depth, be sure to check out the Serenity Dojo "BDD Requirements Discovery Training" - it covers all of this stuff in a LOT of detail.

Enjoy!