Who writes the BDD feature files and scenarios? and when do they get written?

The straightforward answer you often see for Scrum teams is “during sprint planning”, and for Kanban teams its “When you pick up the story”. The problem with these answers is they don’t include many factors that could frustrate teams or make adoption difficult.

If your initial reaction to this is “our QA/testers write them during testing with Cucumber” then you might want to consider if you are really doing BDD, and is Cucumber/SpecFlow/Behat an appropriate tool for you. My previous post When not to use Cucumber could guide you through.

Now if the product owner/business analysts, developers and testers are all involved in the discussing and capturing examples (Scenarios) then let's consider the ‘When’ and ‘Who’ questions.

Writing features files using Gherkin seems simple at first but writing them well can be difficult. Teams often get into deep discussions in how a step should be written, combining steps or if a step is a ‘Given’ or ‘When’. If the writing of the feature file (Capturing the conversation) takes place during sprint planning with many people will have an input on the Gherkin and the conversation moves away from the discussion of the User Story using examples, and then wastes people's time by focusing on the discussion on the Gherkin.

To stop session like sprint planning with greater than 3 participants descending into a discussions on writing Gherkin, we encourage teams to capture the examples from the conversation on sticky notes (Post-it notes) using just 1 or 2 short sentences. Sticky notes are easy to tear up and quickly new ones can be written when examples are refined and new ones discovered. These sticky notes are your real examples that will help the team scope and estimate on User Stories, you don’t need a full feature file in Gherkin to do that.

Using sticky notes changes the answers to the ‘when’ question into a phased approach:

Have the conversation about the User Story using BDD techniques during Sprint Planning and capture the examples on sticky notes.

Take away the sticky notes to be written up into Gherkin after the planning session; taking a photo with a smartphone is very good for this.

The written up features are shared amongst the meeting attendees to make sure nothing has been missed. You’ll often find Gherkin discussion coming out at this stage, but less so for mature teams as they will have a settled style.

So ‘who’ writes up the sticky notes into ‘Given When Then’?

I would discourage any knee jerk reactions to say the “testers, because they are the ones who automate with Cucumber”. When making this decision you need to look at everyone's skills and time availability within the team. For some the product owner will have the capacity, for others it will the developers.

The best approach we find, particularly for teams new to BDD, is to use a pair to write the scenarios and feature files. The pair combination bring different perspectives to writing the scenarios, particularly if they are from different roles, and this can avoid a lot of the ‘Gherkin’ discussions elevating to the team level when a feature file is shared. Pairing also a great technique for on-boarding a new team member with Gherkin and BDD.

What if I’m not using Scrum?

In my example I’ve been focusing on Scrum and sprint planning, but looking at other situations I use this guiding principle: “Have the conversation about the User Story as close as possible to work starting on it”. The reason for this principle is User Story conversations have a half-life, that is the shared understanding built up by a team degrades over time.

The sticky note and write-up afterwards technique is still applicable outside of Scrum, but you only need to use it when you have more than three participants in a discussion.

Summary

When people are having conversations about User Stories, make sure they focus on the discussion at hand and it doesn't evolve into a technical discussion on a supporting technique like writing examples in Gherkin. Sticky notes are a great for capturing examples, ideas and questions during conversations without getting in the way.