Getting into the BDD rhythm

John Ferguson Smart | Mentor | Author | Speaker - Author of 'BDD in Action'.
Helping teams deliver more valuable software sooner3rd October 2018

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.

Like To Learn More? Learn How To Write BDD Scenarios Like A Pro!

Writing BDD scenarios is a bit of an art. And it's about more than just the scenario-writing - there's a whole process you need to embrace to get optimal results.

If you'd like to understand how to write highly effective BDD Scenarios, ones that can make a real difference in your projects, you need to check out this training course.

This in-depth 4-hour training containing over 30 modules will show you:

  • How to get more clarity about the real user requirements sooner (and to uncover the stuff they forgot to tell you!)
  • How to leverage your QA skills earlier in the development process, so you stop wasting your time on poorly written requirements and hard-to-test features
  • How to facilitate and guide conversations with business folk and other team members more effectively, so that you can uncover edge cases and missing requirements sooner
  • How to write powerful and expressive acceptance criteria using Gherkin, the language of tools like Cucumber and SpecFlow
  • The five essential qualities of highly effective acceptance criteria

You can check out the training here

© 2019 John Ferguson Smart