BDD 101: Behavior-Driven Agile

Previous posts in this 101 series have focused heavily upon Gherkin. They may have given the impression that Gherkin is merely a testing language, and that BDD is a test framework. Wrong: BDD is a full development process! Its practices complement Agile software development by bringing clearer communication and shift left testing. As such, BDD is a refinement, not an overhaul, of the Agile process. This post explains how to add behavior-driven practices to the Agile process. (Check the Automation Panda BDD page for the full table of contents.)

Common Agile Problems

User stories can sometimes seem like a game of telephone: the product owner says one thing, the developer makes another thing, and the tester writes a bad test. When the test fails, the tester goes back to the developer for clarification, who in turn goes back to the product owner. Hopefully, the misunderstanding is corrected before demo day, but time is nevertheless lost and resources are burned. Acceptance criteria for a user story should clarify how things should be, but often they are poorly stated or entirely missing.

Another Agile problem, especially in Scrum, is incomplete testing. Development work is often treated like a pipeline: design -> implement -> review -> test -> automate -> DONE. And stories have deadlines. When coding runs late, testers may not get testing done, let alone test automation. Add a game of telephone, and in-sprint testing can become perpetually impeded.

BDD to the Rescue

BDD solves both of these Agile problems beautifully through process efficiency. Let me break this down from a behavior-oriented perspective:

  • Acceptance criteria specify feature behavior.
  • Test cases validate feature behavior.
  • Gherkin feature files document feature behavior.

Therefore, when written in Gherkin, acceptance criteria are test cases! The Gherkin feature file is the formal specification of both the acceptance criteria and the test cases for a user story. One artifact covers both things!

The Behavior-Driven Three Amigos

The Three Amigos” refers to the three primary roles engaged in producing software: business, development, and testing. Each role brings its own perspective to the product, and good software results when all can collaborate well. A common Agile practice is to hold meetings with the Three Amigos as part of grooming or planning.

The BDD process is an enhanced implementation of The Three Amigos. All stakeholders can participate in behavior-driven development because Gherkin is like plain English. Feature files mean different things to different people:

  • They are requirements for product owners.
  • They are acceptance criteria for developers.
  • They are test cases for testers.
  • They are scripts for automators.
  • They are descriptions for other stakeholders.

Thus, BDD fosters healthy collaboration because feature files are pertinent to all stakeholders (or “amigos”). Features files are like receipts – they’re a “proof of purchase” for the team. They document precisely what will be delivered.

Behavior-Driven Sprints

To see why this is a big deal, see what happens in a behavior-driven sprint:

  1. Feature files begin at grooming. As the team prepares user stories in the backlog, acceptance criteria are written in Gherkin. Since Gherkin is easy to read, even non-technical people (namely product owners) can contribute when The Three Amigos meet. Techniques like Example Mapping can make this collaboration easy and efficient.
  2. During planning, all stakeholders get a good understanding of how a feature should behave. Better conversations can happen. Clarifications can be written directly into feature files.
  3. When the sprint starts, feature files are already written. Developers know what must be developed. Testers know what must be tested. There’s no ambiguity.
  4. Test automation can begin immediately because the scenario steps are already written. Some step definitions may already exist, too. New step definitions are typically understandable enough to implement even before the developer commits the product code.
  5. Manual testers know from the start which tests will be automated and which must be run manually. This enables them to make better test plans. It also frees them to do more exploratory testing, which is better for finding bugs.

Overall, Gherkinized acceptance criteria streamline development and improve quality. The team is empowered to shift left. On-time story completion and in-sprint automation become the norm.

(Arguably, these benefits would happen in Kanban as well as in Scrum.)

New Rules

In order to reap the benefits of BDD, the Agile process needs a few new rules. First, formalize all acceptance criteria as Gherkin feature files. In retrospect, it should seem odd that the user story itself is formalized (“As a ___, I want ___, so that ___”) if the acceptance criteria is not (“Given-When-Then”). Writing feature files adds more work to grooming, but it enables the collaboration and shift left testing.

Second, never commit to completing a user story that doesn’t have Gherkinized acceptance criteria. Don’t become sloppy out of expediency. Use the planning meeting as an accountability measure.

Third, include test automation in the definition of done. Stories should not be accepted without their tests completed and automated. Automation in the present guarantees regression coverage in the future, which in turn allows teams to respond to change safely and quickly.

Advanced Topics

Check out these other articles for further learning:

More Agility through Automation

BDD truly improves the Agile process by fixing its shortcomings. The next step is to learn BDD automation, which will be covered in the next post. Until then, I’ll leave this gem here:



  1. Hi Andy,
    I have a question about formalizing acceptance criteria as Gherkin feature files:
    The way I understand it, acceptance criteria might translate into either unit tests, integration tests or UI tests. But PMs would not want to be bothered with this distinction.
    So would I include all types of tests into one feature file?
    Or should I prevent mixed-type acceptance criteria in the first place (or maybe acceptance criteria should only be UI tests)?


    1. If your team is using BDD and Gherkin for collaboration, then I strongly recommend NOT writing unit tests in Gherkin. Unit tests should be a low-level code exercise for the developer. Gherkin scenarios should be integration and end-to-end tests (or “UI” tests). Don’t focus on those distinctions, though. Instead, separate “unit tests” (white box; for the developer) from “feature tests” (black box; integration, end-to-end, UI). Feature specs are feature tests, so write those in Gherkin and then automate them. PMs should never really see unit tests.


      1. Thanks for your answer. So we will not distingiush within “feature” tests.

        About unit tests: We did an “examplary example mapping” in a fictitious scenario, during which some people came up with rules+examples that to me seemed to work best as unit tests.
        So in my summary of our example mapping, I became a bit too fixated on also translating those rules into Gherkin, so they could find them again in the outcome.
        But now that I think of may question again, I find it totally obvious that you’re right about excluding unit tests from Gherkin.


  2. Hi Andy, What’s your opinion about automating the same GWT in multiple applications. For example, if I want to provide the customer with a way to checkout, the client has work, multiple API applications may have work. All of them need to do something to satisfy the business requirement, however the true business logic may only live in one layer (the 2nd api layer). The client does some thing to consume and display properly, the middle API app may do some authentication and the 3rd layer API app has the business logic. Where would you automate the GWT in isolation (with mocks)?


    1. Hi Julie!

      This is definitely possible. One question to ask is this: how much of the lower layers must be explicitly spelled out in Gherkin scenarios? Many times, lower-level operations like authentication mechanics and service calls are never really seen by the end user – all they see is a front-end application like a Web page. Gherkin scenarios should specify behaviors, not implementations. What matters is that, for example, a user could see their profile page, not that some REST API endpoint got authenticated and returned 200 with a structured JSON body.

      If you decide that your Gherkin scenarios truly must explicitly call out other apps or systems, that’s totally possible, too. Just make sure your automation code can handle it!

      Be careful where you use mocks. I would probably recommend against mocking apps/services because Gherkin is more suitable for acceptance and end-to-end testing, but nevertheless, you could. Using mock/fake test data/config would be okay, though.

      I hope this helps!


  3. I really think, that definition of expression “Scenario” or “Scenario Outline” in Gherkin is not very appropriate. These are definitely “Test Case”‘s from fundamental testing point of view, and the “Feature” should be pointed as Test Scenario then. Anyway this is only one thing up to now what I think is wrong, everything else is great 🙂


    1. Scenarios are much more than just test cases, though. They are behavior specifications. They represent requirements and acceptance criteria. They explain how a feature should work with concrete examples. That’s why they are called “scenarios” and not “test cases.”


      1. A manual test case is simply a list of steps to be executed by a human tester. Gherkin scenarios are test cases as well as specs because they list those steps. Extra info can be added via comments to help inform manual testers, too.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s