A BDD story consists of one narrative followed by at least one scenario. A narrative is only informative, and its main purpose is to provide just enough information that can serve as a beginning of communication between everyone involved (testers, business representatives, developers, analysts, and so on). It is a short and simple description of a feature, told from the perspective of a person who requires it.

The goal of a narrative is to answer three basic questions:

1. In order to: What is the benefit or value of the feature that should be built?
2. As a: Who needs the feature that was requested?
3. I want to: What is the feature or goal that should be developed?

Once we have those questions answered, we can start defining what we think would be the best solution. This thinking process results in scenarios that provide a lower-level of detail.

Until now, we were working at a very low-level using unit tests as a driving force. We were specifying what should be built from the coder's perspective. We assumed that high-level requirements were defined earlier and that our job was to do the code specific to one of them. Now, let us take a few steps back and start from the beginning.

Let us act, let's say, as a customer or a business representative. Someone got this great idea and we are discussing it with the rest of the team. In short, we want to build an online book store. It is only an idea and we're not even certain of how it will develop, so we want to work on a Minimum Viable Product (MVP). One of the roles that we want to explore is the one of a store administrator. This person should be able to add new books and update or remove the existing ones. All those actions should be doable, because we want this person to be able to manage our book store collection in an efficient way. The narrative that we came up with for this role is the following:

In order to manage the book store collection efficiently 
As a store administrator 
I want to be able to add, update, and remove books 

Now that we know what the benefit is (managing books), who needs it (administrator), and finally what the feature that should be developed is (insert, update, and delete operations). Keep in mind that this was not a detailed description of what should be done. The narrative's purpose is to initiate a discussion that will result in one or more scenarios.

Unlike TDD unit tests, narratives, and indeed the rest of the BDD story, can be written by anyone. They do not require coding skills, nor do they have to go into too many details. Depending on the organization, all narratives can be written by the same person (a business representative, product owner, customer, and so on) or it might be a collaborative effort by the whole team.

Now that we have a clearer idea regarding narratives, let us take a look at scenarios.