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).
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).
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.
2 responses to “Why I am a big fan of Dan North and behaviour driven development”
[…] experience? Even if you don’t test with customers prior to launch, you should test some key acceptance scenarios internally before launch to make sure the product works as […]
[…] product and then work backwards. Then getting stuck into the detail of a product backlog or writing user stories to implement the […]