Getting into the BDD rhythm

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. More importantly, they stand a much higher chance of delivering the solutions the customer actually needs.

The benefits of BDD are obvious. But then so are the benefits of exercise, and we don't all do as much of that as we should either. When the pressure is on to deliver, it is 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.

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
• Block time before each sprint, and stick to it!
• "The story ain't done till the scenario's run"

Start with the collaboration

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. Start with the conversations. It doesn't have to be the whole team discussing every single story (that's why we call requirements discovery sessions the "3-amigos" and not the "BDD-posse"). But make sure the conversations happen.

Block time before each sprint

But how do you ensure that these conversations do happen? A great way is to block off a morning each week before a new sprint starts to do requirements discovery sessions. 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.

Never mix discovery and planning

Discovery should be before and separate to any sprint planning activities (see next point) - never mix discovery and planning. Requirements Discovery sessions are creative, fluid process where practices like example and feature mapping work well, and which tend to be more effective in smaller groups (say 3-4 people). Planning activities need the whole team, so they should be short and snappy, and not drag on in endless discussions about implementation choices. Rather than analyse each new story, present the gherkin scenarios that came out of the requirements discovery activities. This makes it much easier to judge the size and scope of a story.

Automate in-sprint

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.

"The story ain't done till the scenarios run"

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.