This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.
- Part 1: Introduction
- Part 2: Narrative
- Part 3: Scenarios
- Part 4: Automation
Narrative
“User stories are a promise for a conversation” (Ron Jeffries)
A BDD story consists of a narrative and one or more scenarios. A narrative is a short, simple description of a feature told from the perspective of a person or role that requires the new functionality. The intention of the narrative is NOT to provide a complete description of what is to be developed but to provide a basis for communication between all interested parties (business, analysts, developers, testers, etc.) The narrative shifts the focus from writing features to discussing them.
Even though it is usually very short, it tries to answer three basic questions that are often overlooked in traditional requirements. What is the benefit or value that should be produced (In order to)? Who needs it (As a)? And what is a feature or goal (I want to)? With those questions answered, the team can start defining the best solution in collaboration with the stakeholders. The narrative is further defined through scenarios that provide a definition of done, and acceptance criteria that confirm that narrative that was developed fulfills expectations.
Narrative: In order to preserve my work As a blog writer I want to be able to save posts
It is important to remember that the written part of a BDD story is incomplete until discussions about that narrative occur and scenarios are written. Only the whole story (narrative and one or more scenarios) represents a full description of the functionality and definition of done.
If more information is needed, narratives can point to a diagram, workflow, spreadsheet, or any other external document.
What distinguishes narratives from requirements?
Since narratives have some characteristics of traditional requirements, it is important to describe distinctions. Two most important differences are precision and planning.
Precision
Narratives favor verbal communication. Written language is very imprecise, and team members and stakeholders might interpret the requirement in a different way. Once I saw following entry in a restaurant menu: “Starter can be a choice of salad or ham and bread”. What could I choose?
Salad or (ham and bread)
(Salad or ham) and bread
The waiter came soon, placed bread on my table, and asked whether I would like salad or ham. All doubt disappeared in a matter of seconds. Verbal communication won over written.
As another example, I saw the following requirement statement relating to a registration screen: “The system shall allow the user to register using 16 character username and 8 character password”. It was unclear whether the username MUST be 16 characters or whether it could be any length up to 16 characters, or whether it could be any length with a minimum of 16 characters. In this particular case, the business analyst removed any doubts as soon as we asked for clarification. However, there are many other cases when developers take requirements as a final product and simply implement them in a way they understand them. In those cases they might not understand the reasons behind those requirements but just “follow specifications”. They might have a better solution in mind that never gets discussed.
Planning
IEEE 830 style requirements (“The system shall…”) often consist of hundreds or even thousands of statements. Planning such a large number of statements is extremely difficult. There are too many of them to be prioritized and estimated, and it is hard to understand which functionalities should be developed. That is especially evident when those statements are separated into different sections that represent different parts of the system or products. Without adequate prioritization, estimation, and description of the functionality itself, it is very hard to accomplish an iterative and incremental development process. Even if there is some kind of iteration plan, it can take a long time for a completed functionality to be delivered, since the development of isolated parts of the system is done in a different order and at a different speed.
Narratives are not requirement statements
The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications. This document is known as IEEE Standard 830 and it was last updated in 1998. One of the characteristics of an IEEE 830 statement is the use of the phrase “The system shall…”. Examples would be:
- The system shall allow the user to login using a username and password.
- The system shall have a login confirmation screen.
- The system shall allow 3 unsuccessful login attempts.
Writing requirements in this way has many disadvantages: it is error prone and time-consuming, to name but two. Two other important disadvantages are that it is boring and too long to read. This might seem irrelevant until you realize the implications. If reviewers and, if there is such a process, those who need to sign off requirements do NOT read it thoroughly and skip sections out of boredom, or because it does NOT affect them, many things will be missed. Moreover, having a big document written at that level often prevents readers from understanding the big picture and the real goal of the project.
A waterfall model combined with IEEE 830 requirements tends to plan everything in advance, define all details, and hope that the execution will be flawless. In reality, there are almost no successful software projects that manage to accomplish these goals. Requirements change over time resulting in “change requests”. Changes are unavoidable and only through constant communication and short iterations can the team reduce the impact of these changes. IEEE 830 statements are a big document in the form of a checklist. Written, done, forgotten, the overall understanding is lost. The need for constant reevaluation is nonexistent.
Consider the following requirements:
- The product shall have 4 wheels.
- The product shall have a steering wheel.
- The product shall be powered by electricity.
- The product shall be produced in different colors.
Each of those statements can be developed and tested independently and assembled at the end of the process. The first image in someone’s head might be an electric-powered car. That image is incorrect. It is a car, it has four wheels, it is powered by electrically-powered (rechargeable batteries) and it can be purchased in different colors. It is a car I bought for my 3-year-old daughter. That is probably not what you would think from reading those statements. A better description would be:
Narrative: In order to provide entertainment for children As a parent I want a small-sized car
By looking at this narrative, it is clear what the purpose is (entertainment for children), who needs it (parents), and what it is (a small-sized car). It does not provide all the details since the main purpose is to establish the communication that will result in more information and understanding of someone’s needs. That process might end with one narrative being split into many. Further on, scenarios produced from that narrative act as acceptance criteria, tests, and definition of done.
Who can write narratives?
Anyone can write narratives. Teams that are switching to Agile tend to have business analysts as writers and owners of narratives or even whole BDD stories (a narrative with one or more scenarios). In more mature agile teams, the product owner has a responsibility to make sure that there is a product backlog with BDD stories. That does not mean that he writes them. Each member of the team can write BDD stories or parts of them (narrative or scenario). Whether all the narratives are written by one person (customer, business analyst, or product owner) or anyone can write them (developers, testers, etc) usually depends on the type of organization and customers. Organizations that are used to “traditional” requirements and procedures that require them to have those requirements “signed” before the project starts often struggle during their transition to Agile and iterative development. In cases like this, having one person (usually a business analyst) as the owner and writer of narratives might make a smoother transition towards team ownership and the impact on the organization.
Good story
A good BDD narrative uses the “INVEST” model:
- Independent. Reduced dependencies = easier to plan.
- Negotiable. Details added via collaboration.
- Valuable. Provides value to the customer.
- Estimable. Too big or too vague = not estimable.
- Small. Can be done in less than a week by the team.
- Testable. Good acceptance criteria defined as scenarios.
While IEEE 830 requirements are focused on system operations, BDD narratives focus on customer value. They encourage looseness of information in order to foster a higher level of collaboration between stakeholders and the team. The actual work being done is accomplished through collaboration revolving around the narrative that becomes more detailed through scenarios as the development progresses. Narratives are at higher level than IEEE 830 requirements. Narratives are followed by collaboratively developed scenarios which define when the BDD story meets the expectations.
Technology Conversations 