Behavior Driven Development

There are at least two processes to manage and execute the development of software. The most common one, especially for large companies or government entities with large data system needs, is the Waterfall development model. It usually goes something like this:

1. The customer comes up with a desired new capability. Perhaps the customer is an emergency relief agency, and wants to automatically track metrics important to them: the number of victims supported, the number of meals supplied, the number of people per shelter, etc.
2. They develop the overall requirements and look to the development team to decompose the high-level requirements into a specific set of decomposed functions.
3. The team validates them with the client and develop a draft Requirements Traceability Matrix (RTM).
4. The team develops a design and validates the design (as much as the client can understand) with the Subject Matter Experts (SMEs).
5. The team links the requirements, design elements, and policy documents together in an RTM.
6. The team develops the software for the system. usually months later,
7. The team finally presents the completed software to the client.

At the final step, the client is either very happy or very upset because it’s been months since they heard from you and the system doesn’t do what they want it to. And besides that, they say it’s awkward, difficult to use, and takes more time than just using spreadsheets for everything. And, most importantly, it took six months and didn’t provide what was wanted.

Avoiding #7 is one of the advantages of Agile development. Using Behavior Driven Development (BDD) in an Agile environment will not make the development process perfect. It won’t make all the code perfect the first time through. And it won’t make the client any less difficult to work with. But BDD will keep the customer involved in the process from the beginning and everywhere along the development process. Because of customer feedback, it ensures there is a minimum of developer missteps, incorrect assumptions, miscommunications or the need to re-write large portions of the software. It keeps the client from wasting money and the developers from working late hours (saving the client money).
Purpose of Behavior Driven Development

Within the overall Agile environment, what is the purpose of BDD?

In general, BDD, using user stories, describes the client’s desired behavior of the planned software for each of the relevant roles. And it is often accomplished by user roles rather than functional grouping. The general assumption is that different users within the organization will do different things with the information. Some will capture the information (e.g. field agents), others will analyze the information (Area Manager and State Managers) and use it in reporting to the next level in the organization.

Going back to the emergency relief example, consider the following scenario:

A series of tornadoes has hit a mid-western area, knocking out power, knocking out water, and destroying hundreds of homes over a wide geographical area. The client (an Emergency Response Team) wants to use a data system to efficiently serve the impacted locales. Those services include providing meals, housing people in shelters, providing water, and supporting the pets of the impacted communities.

In this scenario, there are many roles. However, we will limit ourselves to three roles. They are:

• Field Agent
• Area Manager
• and State Manager

The first step in a BDD project is the development of user stories. User stories describe what I, as a user in a particular role, want the system to enable me to do. The following three User Stories describe the behavior the developers are to create.

User Story 1

As a Field Agent, I want to be able to capture the number of people being cared for every hour, the amount and time of water deliveries, the number of meals received and delivered by time, and the capacity of the shelter (number of beds) All the data should be listed in tabular form so I can manage the activities of the shelter.

User Story 2

As the Area Disaster Manager, I want to be able to list all of the shelters, showing the name of each shelter manager, the name of each shelter, the number of people in each shelter, and the last delivery of water to each shelter so I can report this information to the State Disaster Manager.

User Story 3

As the State Disaster Manager, I want to be able to create a report that combines all the data from the Area Disaster Managers’ reports so that I can report to the National Disaster Manager.

Advantages of the Use of BDD

As mentioned in this Agile Project Management article, Agile is a set of principles, not a process. Agile determines or controls the processes used. BDD is a part of the development process that takes the Agile principles into account. In fact, an Agile approach must be used in order for BDD to be effective.

Take the second user story as an example. It says:
As the Area Disaster Manager, I want to be able to list all of the shelters, showing the name of each shelter manager, the name of each shelter, the number of people in each shelter, and the last delivery of water to each shelter so that I can report this information to the State Manager.
As early as possible, the developers must communicate with the users/client to clear up possible ambiguities. In this user story, the ambiguities include:

• How should the report be configured?
• Is it a tabular report? If it is tabular, where should the data be listed in the report? Should the first column be the name of the shelter or should the first column be the name of the area?
• Are the contents of any of the columns dependent upon the contents of other columns? What is the relationship between the columns?

This is by no means an exhaustive list of possible questions. But it should illustrate the power of communications between the client and the developers. There are many other questions possible for this single user story. Through discussions with the user, the developers are able to build a specification, a sort of plain-language description of what the software will do. The ambiguities are resolved in the specifications.

You may end up with a specification that says something similar to the following:

• The system shall look at all shelter records
• For each shelter record, when the name of the area matches the input field Area_Name, the system will use the shelter data
• Where the data fields associated with the shelters are quantities, (e.g. # of bottles of water delivered, # of shelter occupants, #of meals served, etc.) the system shall add the quantities of these fields (sum of # of bottles of water, sum of meals delivered, sum of people housed, etc.)
• The system shall present the tallies in the Area Manager Report columns

Obviously, the system could provide many additional capabilities. One of the advantages of using BDD is it encourages the development and identification of those additional capabilities. For instance, since I am tracking the number of occupants, would it be useful to track that number throughout the day? Would it improve efficiency if we know what time the water deliveries take place as well as the number of bottles? Would it be good to track the times the meals are delivered? Would the user best be served to receive the information in a report (tabular) or a narrative?
BDD helps you see the behavior you want from the software, and it also aids in brainstorming for identifying future capabilities and the creation of a backlog. But it all depends on free-flowing communications between the user/client and the developers. And of course, it means you should be talking to designated experts within the user community.

Disadvantages of BDD

We all know there is no “silver bullet” that addresses all of the pitfalls and barriers to productive software development. Every solution has one kind of downside or another. The primary “disadvantages” of BDD are two-fold. Because communications between the user and the developer are essential, if the user if not available, it will be difficult to work past ambiguities and questions generated by the user stories.

The second disadvantage is the need to dedicate a team of developers to work with the client. The short response time required for the process means high levels of availability. However, if the client organization has a good understanding of what is involved in a development project based on Agile principles, the client expert will be available when needed. And if the development teams perform as efficiently as they can, their demands on the client expert will be minimized.

From the developer’s perspective, proper resource planning can avoid conflicting resource demands.

Which Comes First?

So which comes first, the User Stories or the Requirements? It all depends on the project. User stories can be used to generate requirements. They can even be used in a Requirements Traceability Matrix (RTM) as a part of the documentation.

If the client would prefer working with the business analysts, the developers can identify the requirements and, also working with the client, can begin to create user stories. The advantage here is that the client begins to see working software almost immediately. As a result, the client can see what they are asking for and what the developers are planning on delivering. And this will generate ideas, guided by their experience, of other activities they want the software to support.

What Follows?

If the client and the user are smart (or at least trying to avoid being crucified by Quality Assurance), several things will happen with respect to documentation.

First, requirements and user stories will be tied together. Design documentation will be created, even if, as is likely, after the fact. Test cases and test results will also be tied to the user stories and requirements. Test cases can be directly related to the user stories. They will be easily verified. And assuming the developers began coding with a clear idea of what the results will be, the testers will have an easier job of testing. They will have objective indicators of what a failure looks like.

An Agile process does not mean the negation of documentation, as tempting as that may be. Rather, an Agile philosophy and BDD processes should result in the creation of complete and effective documentation.