I believe that “behaviour-driven development” (‘BDD’)  is one of those techniques that when you have done it once, you are likely to keep applying it. BDD was first introduced by Dan North, a well known Agile and Lean technology specialist, and is great tool for specifying and communicating the behavioural changes that one wants to achieve.

BDD typically starts with defining business or user outcomes, and then drills down into a feature set that will achieve those outcomes. The key elements of a story are: Title (one line describing the story), As a (role), I want (feature) and So (benefit).

For example:

Story 1

Title: Running out of ice cream alert

As an ice cream lover

I want to get an alert as soon as I am running low on ice cream in my freezer

So that I can order new ice cream and never have to run out of ice cream

A story is then accompanied by acceptance criteria, which are usually presented as “scenarios”. These scenarios are meant to help establish when a feature is “done”, or complete. The key elements of a scenario are: Title (one line describing the scenario), Given (context), And (some more context) and Then (outcome).

For example:

Scenario 1

Title: Number of ice cream tubs is running low

Given that I have turned on my ice cream alert

And there are less than 5 tubs of ice cream left in my freezer

When I open the door of my freezer

Then I receive an alert on my phone letting me know that I am running out of ice cream and I can order my ice cream and fill up my freezer

Now that I have given a quick flavour of what BDD is all about, let me explain why I am such a big fan of this approach:

  • It provides a common language through which people can communicate what it is they are trying achieve and the scope of the work involved.
  • It is an “outside-in” approach which means that the initial focus is on identifying the business and/or user outcomes, making sure people are clear on what ‘done’ looks like.
  • Stories and scenarios are testable, irrespective of whether testing is done in automated or manual fashion.
  • Defining stories and scenarios helps to spot any gaps or edge cases early on in the process, especially if you involve the key people involved from a range of disciplines.
  • None of these stories and scenarios are set in stone, but are likely to evolve and expand. This fits well with products that are developed in an iterative manner.
  • In my view, a good story or scenario is unambiguous in terms of the outcomes it aims to achieve and provides something which can be measured.

Main learning point: As much as I am a fan of Dan North and BDD, I know that there a lot of people out there who are less passionate about this approach. For example, they feel that BDD can be too prescriptive or test oriented. I would love to hear from (non) fans to learn how other people do or don’t use BDD and what they see as its main benefits or pitfalls.