A Story in BDD plays the same role in development as an XP Story but is just a tiny-bit more formal.
To smooth it’s path through the development process, we say that it must fulfill certain additional criteria.
A story should have a Title, a Narrative and AcceptanceCriteria.
The Title gives us a label to use to describe this piece of function throughout the life of the project.
The Narrative gives us a brief description of what to deliver, and why we should deliver it (in the form of Features and Benefits.
The AcceptanceCriteria, which 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. We are strong believers in DomainDrivenDesign and use stories and story finding as mechanisms to help construct a UbiquitousLanguage for the domain.
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. However a TechnicalStory still has to provide verifiable business value so that it can be weighed and prioritized alongside any other stories. Naturally it also needs its own suitably defined acceptance scenarios.
We use Technical or Systems Analysts, or Architects to help us get the language right. This leads us to the idea that the customer for a system may change from story to story. There are some interesting planning implications to this which we will describe later.