Originally posted at specflow.org, 22 June, 2020

Even as we slowly open offices, remote work remains the norm. The sudden shift to remote work clearly exposed the importance – and challenges – of remote collaboration. Now that a few months of experience has helped us understand the scope of the challenge, it is a great time to consider how we can use methodologies like BDD to improve remote collaboration.

Collaboration is a value that is frequently emphasized in agile software projects. However, in many cases, the concrete actions stop at creating cross-functional teams (including both devs and testers), inviting more people to the meetings or accommodating everyone in the same room. Unfortunately, this is very rarely enough to allow true collaboration to unfold. True collaboration focuses on people working with each other, not just working next to each other. In a remote environment, this difference is exacerbated. When social interactions are limited, problems can remain hidden for a much longer time.

To achieve collaboration in remote environments , some sort of facilitation is necessary. There are plenty of ways to facilitate collaboration; in this article we are focusing on how teams can collaborate in understanding, documenting and verifying business requirements in remote environments. Production issues, change requests and rework commonly originate from requirements. Think about ambiguous, missing or unclear requirements, but also about conflicts caused by different assumptions! Using BDD for online distributed teams can reduce the probability of these issues by facilitating collaboration around requirements. 

In this series, we are going to focus on three areas of remote collaboration related to BDD:

• Part 1 – Collecting examples online: How the example guided specification approach can be used in remote environments to build a shared understanding
• Part 2 – Driving development with Gherkin: How the expected behaviour can be efficiently documented using the Gherkin syntax so that it provides an exact guidance for remote team members working in a distributed setting
• Part 3 – Making living documentation accessible: How you can improve remote collaboration by making the BDD scenarios and their status easily accessible for the team members and other stakeholders

Collect examples online

In remote environments, feedback loops are generally longer because people work alone more…and longer. As a result, the impact of requirement-related issues are amplified. BDD enables collaboration on the requirements before the actual development starts. It does this using the concept of specification by examples.

Concrete examples help; discussions lead to a better and shared understanding of the requirements. This approach is a natural way of learning that puts the concepts represented by the requirements into context. Discussing the requirements with the help of examples in a project applying BDD is often referred to as the “Discovery” practice.

Due to its nature, the discovery practice works best when the team discusses the requirements together, on an online meeting. The discussion of a user story usually generates 5 to 20 illustrative examples. Without any live discussion, either the feedback loops are too long or the examples become the written specification (with its usual problems). 

Collecting examples can be started by focusing on simple questions, like “Could you please give an example for this?” However, the best practice is to consider facilitation  techniques like Example Mapping or Feature Mapping. During the discovery session, we collect examples for the user story being discussed. The mentioned techniques further improve collaboration by providing a good (visual/spatial) overview of the problem and allowing people to collaborate using different techniques (reading, writing, arranging, etc.) besides talking. This can be achieved by capturing the examples on virtual cards and arranging them logically.

These conversation techniques can be easily adapted to a remote setup with the help of tools that allow creating and arranging virtual cards, e.g. Miro, Google Sheets or Excel for the web. These tools support collaborative editing (simultaneous editing by multiple participants) and allow participants to drill down to get a better overview or to focus on  particular details. (A freely-available Google Sheets / Excel template for example mapping can be downloaded here.) I have also heard about teams doing discovery workshops with mind mapping tools or even with a simple hierarchical list.

A remote discovery session is usually organized as an online meeting a few times a week. The product owner (PO) prepares the discussion of the user story by collecting the acceptance criteria (rules). They can prepare a few key examples as well, but I usually recommend against  “presenting” these examples so that the team can discover them instead. Otherwise, the meeting quickly falls into a presentation. Remember, we want to facilitate collaboration! 

During the online discovery meeting, the team can nominate a facilitator for collecting and capturing the examples. The facilitation is not a difficult job; anyone can do it. I recommend choosing a different facilitator for each occasion. It fosters team spirit and the discussions become more engaging. You can find further tips for facilitators in this post.

Our goal with collecting examples is to establish a shared understanding. When working with BDD, these examples can later become BDD scenarios. (The majority of them usually do.) Even though we know we will use these examples as scenarios, usually we don’t capture them in Given/When/Then style. A properly phrased scenario requires additional considerations, like proper grammatical structures, the review of existing steps, or the use of precise terminology. While all these things are important, doing them at the discovery workshop is not efficient and breaks the creative thinking we would like to focus on. Spend the precious time when everyone is together at the online meeting for those discussions that cannot be distributed.

At this stage, it is perfectly acceptable to capture the examples as a list of steps that describe the behavior of the system in a particular case. It might help if we separate the context, the action, and the outcome parts of these examples though.

You can let the facilitator put down the examples, but you can also let other team members help: Whoever has come up with the example can capture it in the chosen online tool. It also makes sense to capture any open questions or assumptions. All artifacts should be shared and owned by the entire team.

By the end of the meeting, all rules should have been discussed and clarified, as well as illustrated with a couple of examples. At this point, the team will have the necessary confidence to start working with the story.

In the next part…

In this part, we have seen how the example guided specification approach can be used in a remote environment. We have seen what an online discovery session looks like and how it helps to ensure a shared understanding.

During the discovery session, we are collecting examples that capture a particular usage of the application in a rough way. We did not want to capture them as BDD scenarios because that would distract our brainstorming.

In Part 2 we will see how we can properly document our rough examples using the Gherkin format with the Given/When/Then keywords. This allows them to drive the implementation of the described feature.