Should User Stories be written in Gerkhin format? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

We write user stories in the standard prescribed As a X I want to Y so that Z. Now with the popularity of BDD and Gerkhin language format for specifying requirements, does anybody has experience in switching their user stories into gerkhin format. Have you found it easier and intuitive to elicit requirements from the business in this format, and have you experienced any benefits in doing so?

Answer 1

You still start each feature with As an X I want a Y so that Z in Gherkin. However this is commonly turned around so that its benefit is its most prominent aspect, e.g. from https://github.com/cucumber/cucumber/wiki/Gherkin

Feature: Some terse yet descriptive text of what is desired
 In order to realize a named business value /*Z*/
 As an explicit system actor /*X*/
 I want to gain some beneficial outcome which furthers the goal /*Y*/

Once you’ve completed this section the rest of the Gherkin feature is the more recognisable Given When Then section, but these are simply examples that highlight the functionality of your feature. They exist with your feature definition, not instead of it.

For more details have a good read through http://dannorth.net/introducing-bdd/

Answer 2

I would continue writing User Stories in the 'As a ... I Want ... So That ...' format and write your Acceptance Criteria using Gherkin.

Answer 3

Throughout my experience with Agile, I have noticed that there is no fixed rule that works for all situations and all teams. The concept of agile is to move away from unnecessary formalism and changes such as these would rather take away from the real agile concept (my POW!)

All the while writing user stories, its more of an evolutionary thing then being fixed. With every new team you have to try and test what works for them. 'Dont fix what aint broke' so if your current user stories are having some problems, point out and go through the problems during a retrospective meeting. Try to follow the changes recommended and agreed to by the team. You would end up getting better user stories.

Answer 4

User Stories already have a simple defined format

As a <Type of User>
I want <To perform some action>
So that <I receive some value>

The Gherkin format (Gherkin is a type of cucumber used to make pickles) is typically used for documenting Acceptance Criteria in software like the Cucumber test automation tool. Get it? Gherkin format used in Cucumber?? Gherkin format uses a Given...When...Then... statement.

Gherkin Format:

Given <A Certain scenario>
When <I perform some action>
Then <I receive some result>

In my experience Acceptance Criteria is written in many different formats from bullet lists to comma separated lists and run-on sentences. As such Gherkin format provides a standard way to describe Acceptance Criteria while preventing complex or compound Acceptance Criteria with its simplified format

Using the simple Gherkin format for Acceptance Criteria has another interesting side benefit. Since Acceptance Criteria must be simple and to the point in this format each detail must be documented in its own Given...Then...Then statement. As such when we begin to look at the number of Gherkin statements for a particular User Story as the number of statements gets beyond 15 or 20 its a sign that our User Story may be an Epic or Feature masquerading as a User Story. That is to say we should slice the User Story into smaller User Stories with less Gherkin Acceptance Criteria statements for each User Story. See the related posts below on the ProDataMan blog for more details...

What makes a good User Story

Acceptance Criteria - Are we done yet?

Definition of Done