We had a problem. With a project deadline approaching faster than a fiber-optic Internet connection, we had to find ways to speed up our processes. Agile methodology…check, development bottlenecks…maximized, 5 hour energy drinks…engage. But we were forgetting one essential ingredient… project requirements. In agile projects, requirements gathering can be ongoing throughout development, and this part of the process can be very slow. Typical steps:
- PM or BA meets with client to flesh out project requirements
- PM or BA composes a spreadsheet with requirements and sends to client
- Client tediously reads through the spreadsheet and approves
- PM or BA converts the business requirements to technical requirements
- Developer codes from the technical requirements
- Developer or BA writes user acceptance tests for each feature
Not only is this list of steps too extensive to be efficient, there are several points in the process where communication can break down and cause error. Someone has to smoothly convert business needs into technical requirements. Developers can lose track of the business needs from technical requirements and code something incorrectly or inefficiently. Acceptance tests can be created and passed without actually addressing the business need. There has to be a better way to accomplish the business goals.
Dan North attempted to fix the break between the business needs and the technical developments by introducing Behavior Driven Development (BDD) several years ago. BDD is based on the classic Test Driven Development, except that it focuses on communicating through a “ubiquitous language” by framing technical development in the language of the business domain. This ensures that a solution that passes acceptance criteria certainly satisfies a business need. In addition, anyone involved with the project can understand requirements described in this format.
OK, so BDD brings developers, analysts, managers and the business together with a common language…but how?
The key to BDD is defining acceptance tests and criteria. Acceptance tests are written in the agile user story framework. They force the upfront definition of what effect a new feature will have, what the business value of the effect is and who the stakeholders are. Acceptance tests (also known as narratives) are typically written in the following form:
| As a [X] |
As a BDD bank customer |
| I want [Y] |
I want an online account dashboard I can login to |
| So that [Z] |
So that I can check my balance at any time |
With a story like this, the business need is made explicit by the “So that I can get some business value statement,” and the technical requirement comes from the “I want some technical feature statement.” We get the “who, why and how” all in the same story. Now that’s efficient.
Now that we know what the business wants, how do we know when we’ve successfully developed a solution? Acceptance criteria are the answer to that question. Acceptance criteria are written as the different scenarios of a narrative. The scenarios describe the expected outcomes for all interactions with the feature. If all the scenarios are successfully passed, then the feature is implemented. Our stories and scenarios make sure that the business needs are satisfied.
| Scenario 1 |
Scenario 1: Successful login with active account |
| Given the initial context |
Given I have an existing account at BDD Bank |
| And I can even add more |
And I enter a valid username and password |
| When some event occurs |
When I navigate to the dashboard |
| Then this outcome will happen |
Then I should see my account’s current balance |
| |
|
| |
|
| |
| Scenario 2 |
Scenario 2: Failed login with active account |
| Given the initial context |
Given I have an existing account at BDD bank |
| When the other possible event(s) occurs |
And I enter a valid username |
| Then this other outcome will happen |
When I enter an incorrect password |
| And it even includes this final bit |
Then I should receive a failed login message. I should be able to have a new password sent to my email account |
Now we have described our stories and scenarios, but how does this save any time? Well, where do I start?
First, requirements in this format can be written or read by anyone. The project manager or business analyst could work with the client to elicit the requirements, or the business can simply send over their narratives. Communication will also be very easy for those who lack technical savvy –“Oh, Mr. CEO…you don’t like to read through a spreadsheet with a bunch of technical jargon and 1500 columns that are irrelevant to you? (Assigned to, ID, Comments, blah blah blah) Well, do you like stories?” That scenario comes straight from How to get a Raise 101.
Second, requirements in this form are both the business and the technical requirements. Add them to a text document to send for approval. Or better yet, combine these requirements with images of the design and everyone will be pleased with your elegant descriptions.
Third, these requirements are all inclusive. Because they force you to specify the business value and all the scenarios that go with it, they minimize surprises down the road. Too often with the classic, “The system shall be very boring” statements, you find yourself doubling back half way through the project and filling in the gaps. No more, “Oh yeeaaahhh, I didn’t think of that scenario. Let me add a new requirement to our spreadsheet.” Furthermore, the acceptance tests and the requirements are one in the same! You have one document, one requirement, and one test. BDD is all you need.
Finally, one of the best parts of BDD is that with greater acceptance, comes greater tools. Dan North originally created a program called JBehave which maps the “given, when and then” statements directly to the Java code and can be executed using eclipse, Apache Ant, IntelliJ IDEA and other development environments. If the outcome is verified the test passes, if not, it fails. So not only do these stories function as the business requirements, technical requirements and the acceptance tests, but they are also self-verifying! Now we are talking efficiency on another level. Since JBehave, there have been other similar programs developed as well. RBehave does the same thing in Ruby. Cucumber is a software tool for running these kinds of acceptance tests and even classifies them as their own language, the Gherkin language. Project management visualizers like JIRA or AgileZen recognize the BDD story language, and will format your stories for easy reading and understanding. To sum it up, the tools for BDD stories and acceptance criteria are awesome.
You might remember that this whole blog started because we had an extremely narrow deadline on a project, and BDD helped us meet our goals. You might also be wondering if I am going to share any actual details with you about that project or just endlessly talk the talk. Well my friend, the following conclusion is for you.
FINAL ACT
(The office is completely vacant, except for a few diligent employees huddled around their desks in the corner)
(Cheetos wrappers scatter the floor, empty 5 hour energies are everywhere and the project manager has started to pull out her hair –this is not a good look)
*Note* The following is (almost) entirely true
Developer: How are we ever going to get this project finished in time?! We only have a month and our requirements phase will take at least a week. Plus who knows how many times we will have to go back and add more requirements, or if the business will even sign off on them! Maybe I should just quit!
Analyst: Simmer down partner! We’ve got BDD on our side! I just met with the client. We determined all of the potential stories and the outcomes for the application. All I have to do is copy and paste them into AgileZen and assign them to all of our amazing developers.
Developer:But what about the technical requirements? What about the acceptance tests? What about spreadsheets and “system shalls” and communicating with offshore?
Analyst: HAHAHA! This is the 21st century, sir. We have technology to do all of that! Running RBehave will tell us if our solution yields the expected outcomes. Offshore will easily be able to understand requirements so thoroughly stated and all of our requirements documentation will be a mirror of our user stories.
Developer: WOW! You are SO smart! We will save loads of time with BDD!
(Now the stories are moving through AgileZen like Frogger through heavy traffic. The PM, BAs, Developers, and the client are all using the same document to check requirements –they are using a ubiquitous language! The acceptance tests are checking themselves and the final product is GLORIOUS).
You see, BDD really saved the day for our team. To be honest, we did not use RBehave or Cucumber to self-verify our requirements, but in the future I definitely will. All joking aside though, BDD requirements really do save a lot of effort and eliminate language confusion. For additional information, start with Dan North’s article “Introducing BDD“. If you are interested in implementing the self-verifying acceptance tests, check out Matt Wynne and Aslak Hallesoy’s The Cucumber Book. In my opinion, it’s one of the best resources out there. Even if you are not running the self-tests, the language is just easy for non-technical people to understand.
The preceding example is an abstraction of the process my team used to develop a web application compatible with all device sizes for a major national retailer. I will add however, that some clients simply prefer the old methods –they are familiar I suppose –and the more modern BDD is not always applicable. If you are using agile methodology, have communication barriers between the business and technical units or just simply can’t stand the mundane nature of the classically written requirement, give BDD a chance and you might be pleasantly surprised with your results.
