John Ferguson Smart

John's latest articles

Who owns your Gherkin scenarios

John Ferguson Smart
Mentor | Author | Speaker - Author of 'BDD in Action'.
Helping teams deliver more valuable software sooner

Gherkin scenarios | Requirements Discovery | Xscale |
January 15, 2018

“In a team practicing BDD, who owns the Gherkin scenarios?” I’ve been asked this question more than once, so I thought I’d pen an answer.

Gherkin is the Given..When..Then notation commonly used to express acceptance criteria in agile projects. It is notably used by Cucumber and other related Behaviour Driven Development tools. Cucumber lets you automate acceptance criteria written in this format, and turn them into “executable specifications” and “living documentation.”

By “own” the Gherkin scenarios, I mean, who is responsible for authoring them?

Let’s go through some possibilities.

Is it the Product Owners?

What about the Product Owner? In Scrum, while anybody can write a user story, the Product Owner is responsible for the Product Backlog, and will typically play a major role in writing the stories. One of the big selling points of BDD is a common language, understood by the business and the development team alike. Surely, if this is the case, the Product Owners should also be able to write the Given..When..Then acceptance criteria?

Or maybe the Business Analysts?

Or perhaps it is the Business Analyst? Business Analysts are traditionally the ones who capture and document requirements, so that sounds like a perfect fit. In many teams, the Business Analysts place the user stories into JIRA, along with their acceptance criteria in a Given..When..Then format. Shouldn’t they be responsible for keeping them up to date?

But what of the testers?

But what about the tester, who will be automating the acceptance criteria using Cucumber or some similar tool? Should she not be the one with ownership of the finer details of the acceptance criteria? After all, she is the one who needs to automate the tests, find the appropriate test data, and integrate the new scenarios into the existing test framework. During this process, the exact wording and structure of the scenarios might need to be modified to fit in with the existing tests.

And the answer is…

And the best answer, in my experience, is…none of the above!

In fact it is a trick question.

The answer is to write the Gherkin scenarios collaboratively. But not the way you think.

Teams that practice BDD get together before each story to understand what the story is about in detail. They talk through examples of how the feature should work, and about what business rules apply. And they agree on a set of unambiguous acceptance criteria that will guide the development process.

You can learn more about this meeting, and its key role in the BDD process here.

In the early days of BDD, we used to try to produce the finalised acceptance criteria in proper Gherkin, sometimes even in an IDE, during this session. This turned out to be full of good intentions but quite inefficient. So we started practices like Example Mapping and Feature Mapping, to focus more on the real business needs, and less on the tools. We come out of this session with a set of acceptance criteria, in the form of concrete examples, business rules and flows through the system, that we can then record and automate using Gherkin.

So who does write the Gherkin scenarios?

And so, to answer the question, who records and who automates? I have found that the approach that works best is when the acceptance criteria are recorded and automated in a pair-programming session, with both the tester or developer (whoever is doing the automation) and the business analyst or product owner. The tester (or whoever will be automating it) clearly needs to take ownership of the scenarios at this stage. But if the tester does the automation alone, there is a risk of the scenarios drifting away from their original intent, as they are absorbed into the existing test suite. To avoid this, the business analyst helps ensure that they are true to their original intent.


If you want to learn some of the finer points of Behaviour Driven Development, be sure to check out the following: