Behavior-Driven Development and Collaboration within Tech Teams

Behavior-Driven Development (BDD) enables collaboration between technical and non-technical members of a development team. Communication among product managers (PMs), design, devs, and Quality Engineers (QEs) makes for a more successful and efficient team and product. PMs use BDD to focus on product behaviors that are most in line with business objectives and minimize resource waste. BDD proposes user stories to describe the expected behaviors of a product. Acceptance criteria (AC) of these expected behaviors are communicated through the user stories. The AC is used by devs when working on a product feature, and QEs reference the AC as they evaluate the completion of a dev’s work.

This isn’t a process that crosses our minds as we work on projects for school or self-learning. As programmers, we tend to jump straight into code with minimal planning. For most, it’s our preference. During my first job search, I hadn’t put too much thought into the communication between product managers and devs. I assumed devs receive general requirements from product managers and figure out specifics during development. I’ve heard this is the case at some companies. Devs write their own stories and acceptance criteria based on conversations with stakeholders. This isn’t the experience at all companies though. 

It’s good to know what to expect when starting your first dev job and how collaboration works among team members. This article covers the goal of BDD, what it consists of, and some of its benefits. It might even convince you to start implementing parts of BDD in your personal projects.

The Goal of Behavior-Driven Development

As a developer, if your goal is to be a good one, you should be asking questions when told to work on a feature. You could accept the task, do the work, and present the finished feature. But how do you measure completeness and success without sufficient guidelines? Do you want to be working on something without knowing its purpose? If general requirements are vague and we don’t ask what the goal of said feature is, there could be continuous churn during different stages of development.

That is where Behavior-Driven Development comes in. The goal of BDD is to guide development, decrease rework from churn, and maintain progression of the product. Product managers write user stories based on their conversations with stakeholders. These user stories are used to gather information on a desired feature in one explicit location to be communicated with the development team. During planning meetings, devs and QEs should take the opportunity to get clarity on specifics. 

Examples:

• What goal are we trying to achieve by adding this feature?
• If you can come up with a better alternative to achieve this goal, bring it up
• What does the ideal user experience look like? (happy path)
• Can the PM or design foresee any error/edge cases? (sad paths)
• If you can foresee edge cases being an issue, bring them up and ask how they should be handled

Getting the most possible clarity during the planning phase helps to better estimate how long developing a feature will take you. It also reduces back and forth conversations that would’ve come up during development had you not discussed the details during planning. Questions might still come up during development, which is perfectly fine. Just make sure to update the acceptance criteria with those discoveries on the user story to keep the rest of the team updated.

What Behavior-Driven Development Consists Of

As mentioned, BDD is directed by user stories. Agile Alliance, a nonprofit committed to supporting the agile community, emphasizes a user story template. This template guides the key pieces of information that should be included in every user story. Here is their template:

• As a (who wants to accomplish something)
• I want to (what they want to accomplish)
• So that (why they want to accomplish that thing)

This format helps communicate intentions to the team. Not only what the product should do, but the objective behind it, and whom it is for. The user story template is more of a beginners guideline. Once comfortable, user stories should use a more informal phrasing. It still communicates the overall intent of a user story without being constrained by the template. Don’t get too caught up in the extreme details on the first go of a user story. The majority of the details emerge during planning meetings with the team. 

Writing User Stories Using Narratives and Scenarios

The details of a user story can consist of narratives and scenarios. Where a user story is a short description of what the user wants to accomplish, narratives and scenarios contain the specifics using the Given-When-Then formula. 

• Given some preconditions
• When some action or behavior is carried out
• Then what are the changes you expect due to a specified behavior

Here is an example of what a user story with narratives and scenarios could look like when talking about an app like Twitter:

Story: User requests to retrieve their Tweet timeline

---

Narrative #1

As an online user
I want the app to automatically load my latest Tweet timeline
So I can see the most recent Tweets

Scenarios (Acceptance criteria)

Given the user has connectivity
When the user requests to see their timeline
Then the app should display the latest Tweet timeline from remote
   And replace the cache with the new timeline

Narrative #2

As an offline user
I want the app to show me the latest saved Tweet timeline
So I can see some Tweets in my timeline

Scenarios (Acceptance criteria)

Given the user does not have connectivity
   And there is a cached version of the timeline
When the user requests to see their timeline
Then the app should display the latest Tweet timeline saved

Given the user does not have connectivity
   And the cache is empty
When the user requests to see their timeline
Then the app should display an empty timeline message

Use Cases

Some development teams like to get more granular with the details. This can come in the form of use cases. For example:

Load Tweet Timeline From Remote Use Case

---

Data:

• URL (where we’re getting the data from)

Primary course (happy path):

1. Execute “Load Tweet Timeline” command with above data
2. System downloads data from the URL
3. System validates downloaded data
4. System creates Tweet timeline from valid data
5. System delivers Tweet timeline

Invalid data – error course (sad path):

1. Execute “Load Tweet Timeline” command with above data
2. System downloads data from the URL
3. System validates downloaded data
4. System delivers invalid data error

No connectivity – error course (sad path):

1. Execute “Load Tweet Timeline” command with above data
2. System delivers connectivity error

Load Tweet Timeline From Cache Use Case

---

Primary course (happy path):

1. Execute “Load Tweet Timeline” command with above data
2. System retrieves data from cache
3. System creates timeline from cached data
4. System delivers Tweet timeline

Retrieval error course (sad path):

1. Execute “Load Tweet Timeline” command with above data
2. System delivers error

Empty cache course (sad path):

1. Execute “Load Tweet Timeline” command with above data
2. System delivers empty timeline message

Validate Tweet Timeline Cache Use Case

---

Primary course (happy path):

1. Execute “Validate Cache” command with above data
2. System retrieves timeline data from cache

Retrieval error course (sad path):

1. System delivers retrieval error

Teams will use different variations of these examples. Whichever works best for you. The point is to use the natural language of the business to make it easy for technical and non-technical team members to communicate.

Benefits of BDD

At a high level, BDD promotes collaboration of all team members. PMs can write user stories without needing in depth knowledge of the domain and then can work with devs on specifics. Devs are given explicit acceptance criteria. QEs know what acceptance tests should cover. If, during planning, questions are brought up that don’t have immediate answers, stories can be pushed further down in the schedule until the information is obtained. 

PMs have the option to re-prioritize stories and change their mind on the details. Communicate with the rest of the team that the acceptance criteria has been updated if it’s a story that is being worked on. Developers know what to work on next based on priority and why, and the how is left up to them.

Takeaways

The key takeaway here is that Behavior-Driven Development both encourages and reinforces collaboration among team members; as well as flexibility with the product and the development process. If you join a collaborative team that practices BDD, now you have an idea of what to expect. If you join a team where devs drive their own user stories, this process gives you an idea of how to stay organized. My suggestion to you is to start implementing some version of BDD in your personal projects. At the very least you can get used to the practice. But even better, BDD allows you to focus on one feature at a time and you start learning how to estimate the amount of time it will take you to do certain things.

Sources:

Agile Alliance. (n.d.). User Story Template. Retrieved August 11, 2020, from https://www.agilealliance.org/glossary/user-story-template/