Let’s run an experiment involving two couples, one old and the other young.
The first couple has dated a few times while the second couple is married with children and grandchildren.
Both the women ask their partners to select a pastry for them.
Which guy would have the greater chance of getting his choice right, the younger guy who has just meet the girl or the older man who has been living with his wife for fifty years?
The grandfather would likely ace the test. He knows his wife’s favorite type of pastry. He will walk into a bakery, place the order and leave immediately. The younger guy would pick a pastry and hope his choice was right.
Solving the communication gap in software development
Software development has a problem similar to what the younger guy faces.
Too often there is a huge communication gap between business and engineers. The former expects too many features without having a firm grasp of the technical limitations and the latter has trouble understanding what business wants.
This results in waste of time and overwork as both the business side and the engineering side are often at cross purposes, and the final product that emerges is complex and barely functional.
Behavior Driven Development is an Agile Development methodology that aims to change this state of affairs.
There are several benefits of BDD:
- Entire software development process is based on a business logic
- Software development is focused on the user needs
- Business critical features are always delivered on priority
- All stakeholders understand the nitty gritty of the process and communicate throughout because of the use of simple language
- High quality code means that the costs of maintenance and project risk is low
The guts of Behavior Driven Development
In the words of Dan North, BDD’s originator it is “an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria. ”
There are two parts to BDD:
- Use examples written in easy to understand language that describes how users interact with the features
- Automated tests designed on the basis of these examples to ensure that the system behaves as specified by business.
A typical BDD project would have the following elements in it:
1. Setting up SMART goals
Most software development process hits snags when business outcomes like “increase in revenue and decrease in operating costs” are not specific enough to be of help in writing software.
BDD solves this problem by having a business goal which has to be SMART (Specific, Measurable, Attainable, Relevant and Time Bound).
2. Impact Mapping
After SMART goals, the Impact Map is designed which helps the team lay out all the ways in which the specific goal can be reached.
An Impact Map is a mindmap that has four levels and looks like this (source)
Impact Map is an Agile requirement gathering technique that provides a visual overview of what steps should be taken to achieve a goal.
“Why” is the goal, and “Who” are the actors (customers or internal teams) who can help achieve the goal. The “How “denotes the ways in which their specific behavior can be impacted, and the “What” lists the steps that the stakeholders need to implement to have the desired impact.
3. Setting priorities
In every project it’s imperative to set priorities so that business gets the most critical features first. This is decided in BDD by using two techniques called value analysis and complexity analysis.
Value analysis lets the stakeholders pick up low cost high value features and complexity analysis is used for picking the right development and collaboration approach to the entire project as well as to individual features.
These techniques can be implemented using a number of different frameworks.
4. Using stories in planning
Because Agile has a very short development cycle there is always the danger that engineers might build something that business doesn’t want, and their entire work might be wasted.
BDD uses stories in ubiquitous language to make everything unambiguous. Every story has a fixed template and looks like this:
Title (one line describing the story)
Narrative: As a [role] I want [feature] So that [benefit] Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title Given [context] And [some more context]... When [event] Then [outcome] And [another outcome]...
Scenario 2: ...
Here is an example of stories in action and how they can be used directly in development: Story: Account Holder withdraws cash
As an Account Holder
I want to withdraw cash from an ATM So that I can get money when the bank is closed Scenario 1: Account has sufficient funds Given the account balance is $100 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should dispense $20 And the account balance should be $80 And the card should be returned
Scenario 2: Account has insufficient funds Given the account balance is $10 And the card is valid And the machine contains enough money When the Account Holder requests $20 Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should be $20 And the card should be returned
Scenario 3: … Business can now write stories around features and have the assurance that there would be no ambiguity.
Conclusion
BDD is a methodology that’s highly collaborative in nature. It assumes that no single person has the answers to all the problems, and it seeks to develop a framework that can streamline collaboration in fast paced Agile environments.
BDD has a simple role: moving the business analysts, developers and testers on the same page so that features that business needs can be delivered without the minimum of delay.
