Behaviour Driven Development (BDD) has provided teams that have adopted it with a number of benefits. Greater technical excellence, test automation, a shared language. But, has BDD delivered on its promise of increased collaboration?
My theory in short… is no. However, it is certainly possible to collaborate using BDD, so let’s look how to make it a reality.
How does BDD help us collabor8?
BDD was originally developed by Dan North with the purposeful design to help teams to collaborate. If we refer to Dan’s quote from his What’s in a story? blog1:
“Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria.”
We can see that it’s intent is to talk about business outcomes and not get into technical details upfront. This means that everyone can be involved in the conversation as it avoids technical jargon and implementation details. It’s describing what features we intend to develop, and tying it back to business outcomes and objectives.
However, there’s more to BDD that allows us to collaborate than discussing business objectives first. It provides a shared language to articulate what we are developing. It’s intent as a shared language is that anyone can read the language and understand how the feature we’re developing is intended to work. To avoid another wordy quote, I’ve come up with a simple definition for this with a bit of paraphrasing from behaviourdriven.org2:
“ BDD aims to explain the behaviour of a system in easy to understand language. This language is shared by the entire development team.”
This shared language has a specific format that teams use. You may have seen me and other Elabor8ers discuss it in previous blogs. The format is:
Scenario: [Title – explains the activity]
Given [some context]
And [some more context]v
When [a single event/trigger happens]
Then [an outcome happens]
And [another outcome happens]And what it looks like using a practical example from the Facebook login process:
Scenario: Signing up for Facebook
Given Fred is signing up for Facebook
And he provides the required details
When he submits his request to signup
Then a Facebook account is created
And Fred’s email address is set as his username
And a confirmation email is sent to Fred
You can see that the scenario is written in plain language. This is BDD’s intent. Everyone can collaborate while talking about the feature, because we can all understand what’s been written about the feature.
However, the written language element which is meant to help shared understanding has also become it’s shortcoming…
Collaboration in BDD is not a given
Why do I say this? Because it’s much easier to work like this…
Either because it doesn’t involve talking to people (and talking to people can be hard work) or because we have fallen into the trap of believing that we only get “real” work done when we’re at our desks. Neither are an excuse or true. By using a technique like BDD we are claiming to be “agile”, but it seems as though we’ve forgotten about this value from the agile manifesto:
Individuals and interactions over processes and tools
This value emphasises that we should be valuing conversations with the people we work with on a daily basis and discussing how are we going to develop this feature. Rather than focusing on perfecting the tooling element of BDD like the written scenarios component or test automation. Like this:
BDD is not just a template on how to write acceptance criteria. However, if we think it is, we are actually using the least effective way of communicating what we intend to develop. Alistair Cockburn3 has developed a graph that highlights how different modes of communication can be more or less effective:
Notice how using paper (or written words in isolation) are the least effective and rich way of communicating? BDD was specifically designed to be at the other end of the spectrum. Having face to face conversations, and even better if this is done in front of a whiteboard. This is the most effective work of communicating. The written format of BDD is simply a by product of the conversations.
So what are we to do? How do we move past the easy path of just using BDD to write our acceptance criteria to get to the the actual intent of BDD? How do we get to teams collaborating together, discussing what they want to develop, using business language and objectives?
Techniques to level up collaboration using BDD
Trying to make the jump from simply using BDD as a way to write acceptance criteria to collaborating with your entire team can be hard. So I want to introduce to you four different techniques that can be used depending on your team’s maturity levels. As your team gets more confident, you can level up to the next technique or use a mix of the techniques. Whatever works best for you.
Level 1 – Story Reviews
Story Reviews are the concept of reading through and reviewing your BDD scenarios with the development team.
Level of maturity:
It’s important to note that this technique is the first level and therefore not the most collaborative approach. It still unfortunately follows that mindset that BDD is more about writing the scenarios. The BA is doing this in isolation of the team, but it does provide the team a chance to get involved and provide feedback before development starts. If collaboration is foreign to your team, this is a good stepping stone.
Steps to run a Story Review:
1. Business Analyst (BA) writes BDD scenarios ahead of the Sprint
2. Read through the scenarios and review with them with the development team (generally in a workshop room with a projector). This step is the collaborative aspect.
3. BA incorporates changes & feedback
4. Development team starts development when the Story is assigned to the Sprint
Level 2 – Story Kickoffs
Story Kickoffs are the concept of visually explaining the Story and BDD scenarios to the development team when commencing development.
Level of maturity:
This technique is the next step up in terms of collaborating with the development team, but again, is not the ideal state. The BA is still writing in isolation to the team, but is using a much more richer and effective way of collaborating using face to face communication and a whiteboard to explain the Story at the kickoff. It gives the team a chance to provide feedback and suggestions on what they are about to develop. You may choose to use a combination of Story Reviews and Kickoffs to get the team even more involved. They will also have a chance to reflect on the Story in between the Review and Kickoff.
Steps to run a Story Kickoff:
1. BA writes BDD scenarios ahead of the Sprint
2. Story Kickoff held when Story is ready for development within the Sprint
3. BA visually explains the Story & each scenario (generally in front of a whiteboard – example below)
4. BA incorporates changes & feedback during development
You can also read through a more detailed explanation of a Story Kickoff4 in one of my previous blogs.
Level 3 – Story Workshops
Story Workshops are concept of the team collaboratively defining the Story and what BDD scenarios need to be covered.
Level of maturity:
The Story Workshop takes a shift from the two previous levels in that it starts to integrate the whole development team in the defining of the Story, rather than being engaged after the fact. I find this works works really well to discover the different perspectives from a developer mindset or a tester mindset and ensuring that all scenarios will be covered by the Story. It also gives the team a chance to start thinking through the technical implementation ahead of the start of development. I like to combined Story Workshops and Story Kickoffs with the teams that I work with.
Steps to run a Story Workshop:
1. BA organises Story Workshop ahead of Sprint
2. Development team defines the Story & highlights what BDD scenarios need to be covered
3. BA writes BDD scenarios
4. Team starts development when assigned to the Sprint
You can also read through a more detailed explanation of a Story Workshop5 in one of my previous blogs.
Level 4 – Pair/Mob BDD
Pair/Mob BDD is the concept of a couple members to all members of the team defining the Story and writing the BDD scenarios together.
Level of maturity:
Pair/Mob BDD is the highest level of the collaboration techniques I’ll be introducing. This is because it takes team maturity and patience to work effectively. This technique gets the team thinking about what are the BDD scenarios that they are writing and how well will they work for all functions involved. A business analyst/product owner will want the scenarios to be readable and define the business objective. A developer will want the scenarios to explain what needs to be developed. A tester will want the scenarios to be easily automatable.
It’s these conversations that really help the team collaborate on what they are developing and critically think about how they go about doing it. Understandably it will take some time for a team to get used to these sessions, but can add a lot of benefit to the team and avoid rework. For example: the business analyst having to change scenarios after receiving feedback, the tester having to alter scenarios to suit test automation. However, one thing to watch out for is getting so bogged down in how the scenarios are written that it becomes more frustrating and painful than adding benefit. Adam Taylor6 shared this exact experience in his talk at CukeUp! Australia 2015: An evolution of BDD and co-creation within a cross-functional team7.
Steps to run Pairing / Mob BDD:
- Team gets together (ahead of Sprint OR when ready for development)
- Defines the Story & writes the BDD scenarios together
- Team starts development when assigned to the Sprint OR immediately!
Using any one of these techniques will help you and your teams to start collaborating with BDD. To get past using BDD as just a way to write acceptance criteria and move towards the original intent of BDD. Go forth and level up!
Further Reading:
References:
- What’s in a story?: Dan North
- Behaviour Driven Org
- Alistair Cockburn
- Story Kickoff
- Story Workshop
- Adam Taylor
- An evolution of BDD and co-creation within a cross-functional team
