Shimon Krokhmal's blog

as we described, The narrative should include a role, a feature and a benefit

“As a [role]
I want [feature]
so that [benefit]”

This template has a number of advantages.
By specifying the role within the narrative, you know who to talk to about the feature.
By specifying the benefit, you cause the story writer to consider why they want a feature.
It gets interesting if you find the feature won’t actually deliver the benefit attributed to it.
This usually means you have a missing story.
if there is one story with the current feature, which delivers a different benefit (and is therefore still useful), then there is a hidden story whereby you will need a different feature to deliver the benefit described.

The scenario title should say what’s different- You should be able to line up the scenarios side by side, and describe how they differ using only the title. It should be obvious from the title whether this is the scenario you care about, compared to the others.

The scenario should be described in terms of Givens, Events and Outcomes
This is the single most powerful behavioral shift in the adopting BDD process.
Simply by getting the business users, the analysts, the testers and the developers to adopt this vocabulary of “given/when/then”, they discover that a world of ambiguity falls away.
Not all scenarios are this simple.
Some are best represented as a sequence of events, described as:

given [some context]
 when [I do something]
then [this happens]
when [I do another thing]
then [this new thing happens]

And so on.

An example is a wizard-style website, where you step through a sequence of screens to build up a complex data model.
It is perfectly appropriate to intermingle sequences of events and outcomes, as long as you get into the habit of thinking in these terms.
One interesting emergent behavior is that the quality of the conversation changes.
You will quickly discover that you have missed out an assumed given, or forgotten to verify an outcome.
By introducing the given/when/then vocabulary, we can dramatically improve the quality of the group interaction.

The givens should define all of, and no more than, the required context:
Any additional givens are distracting, which makes it hard for someone looking at the story for the first time – whether from the technical or business side – to understand what they need to know.
Similarly any missing givens are really assumptions. If you can get a different outcome from the givens provided, then there must be something missing.

The event should describe the feature :
The event itself should be very simple, typically only a single call into the production code. As discussed above, some scenarios are more complicated than this, but mostly the scenarios for a story will revolve around a single event. They will differ only in the context (the givens) and the corresponding expected outcomes.

The story should be small enough to fit in an iteration :
There are no hard and fast rules about how you do this, as long as you break it down into demonstrable chunks.
In general if there are more than about five or six scenarios, a story can probably be broken down by grouping similar scenarios together.
 

When we need to understand what a computer system is supposed to do so that it can best serve some business need, questions like:
• What is the most important thing the system should do?
• What is the next most important thing the system doesn't yet do?
• If we were to switch off the system, where and what would be the biggest impact?

These Powerful questions can be tough to answer.
But following these will guide us to insights that we hadn't though of.

the Acceptance Criteria consist of a collection of Scenario allow us to determine when we are done, The most important aspect of a story is the language in which it is written.
The golden rule is that the Story should be written in the language of the Role, that is to say the beneficiary of the feature.
If the Story represents a business feature, it should be written in business terms with the aid of a business analyst.
If the story describes a technical requirement, such as resilience or scalability (sometimes called “non-functional” requirements), it should be presented in the appropriate technical language.
Acceptance Criteria specify, as a collection of Scenario, what needs to be achieved if the Behavior of the Feature is to be considered finished.

A Scenario:
Some Behavior that can be automatically verified once the Story (or some part of it) is delivered.
The Scenario sets up the world in a known state (or in a way that will behave deterministically) and executes a sequence of one or more Events resulting in one or more verifiable Outcomes.
We commonly implement these scenarios, as FIT fixtures, Selenium tests or programmatically as code, but the technology is less important than the concept here, the aim of these verifiable scenarios is to define what a successful outcome looks like.

This use of Scenarios gives us two immediate returns.

• They form the basis for our estimates, leading to more consistent estimates than story-level estimations.
• They show when a story is trying to do “too much”.
  If there are more than a handful of scenarios (five or six), it suggests that the story should be split into several smaller stories, each providing independent benefit, and each consisting of a subset of the scenarios.
  Boundary or exception cases are good examples of this: sets of boundary scenarios might clump together to describe common business cases, and some of these clusters will be deemed more important than others. Smaller stories means finer-grained control over prioritization, finer grained visibility of progress and reduced exposure to technical risk.

Scenario structure:

Scenario 1: Title
Given [context]
And [some more context]…
When  [event]
Then  [outcome]
And [another outcome]…

the nerrative Gives us a brief description of what to deliver,
and why we should deliver it (in the form of Features and Benefits).

we shall define few terms:

A Role:
Is an aspect that describes the person, or thing, that will benefit from the Feature.
It is essentially the same as an Actor in a UseCase.

A Feature:
It describes something that the system should do (the behavior, as it were).
An important aspect of a Feature is that it is described solely in business terms and not in terms of technology or technologists,
unless of course the business is technology or technologists!!

A Benefit:
This is the reason we are delivering a particular Feature– it describes the business value accrued from this Feature.
Initially the Benefit is usually qualitative,
but we usually expect to see some quantitative business value assigned to the Story before it is chosen for development.
This is to help keep us honest and to ensure that we are focusing our development efforts on Features that have real business value.

To ensure that we don't forget any of these critical components we often use a template for the narrative like this:

As a <Role>
I want <Feature>
So that <Benefit>

A concrete example may be something like:

As a Developer
I want to be able to rename classes
So that I don’t spend too much time worrying about getting the name right first time

The reason for this degree of formality is that it helps us avoid some common analysis anti-patterns.

Two in particular are worth mentioning: 

• Feature = Benefit.
  This is where the “benefit” is simply a restatement of the feature, this is a common failing in technical or semi-technical customers,
  who wish to promote a particular technical solution.
  These requirements can often be (diplomatically) eliminated, reducing complexity, risk and the associated cost.
• Feature ≠> Benefit. (“Feature does not imply benefit”)
  The feature described will not deliver the benefit described.
  When this occurs it often reveals hidden requirements.
  It may be that the Feature delivers a completely different benefit which we hadn't identified.
  Conversely, we may need to introduce some new Feature to actually achieve the specified Benefit,
  a previously hidden, and thus unplanned, feature.

if you haven't read the introduction yet, please read the introduction to BDD

What is this story all about ?
The idea is that the words you use influence the way you think about something.
To smooth its path through the development process, We say that it must fulfill certain additional criteria.

A story should have a Title, a Narrative and AcceptanceCriteria:

Title:

Gives us a label to describe this piece of function throughout the life of the project.
It is important to choose good titles to describe the story,
Since the story is an atom of development and as such is referred to in all sorts of conversations throughout the life of the project.

Poor titles for stories are things like: 
   • Implement Performance Enhancements 
   • Move Data 
   • Create Persistence Layer

Titles should describe the story in business terms, and should make sense when,
For example, considered as a unit of value for the system.

Some examples of better titles may be: 
   • Accept Credit Card Payment 
   • Confirm Exchange Rate 
   • Accept Product Updates