Behavioral Driven Development (BDD) provides a communication mechanism across all the roles required for requirements and software development (customers, managers, marketing, analysts, development, test, architects, release management). Since BDD scenarios are expressed in the language of the user, the practice of using scenarios across all those roles gets people familiar with how users get work done, and talking to each other (regardless of role) in this language. Also, these BDD scenarios can drive automated tests to provide pass or fail status on what behaviors are in the software. Because these behaviors are written in the language of the user, the tests “talk to us” by being “live” documentation that express how the software is working.

Why BEHAVIORAL?

Software engineering requires coordination of groups of people with different roles and likely from different organizations. Doing well at communicating and coordinating is going to be a hard! For the past fifty years, the IT industry has traditionally tackled this by producing and working with the following:

Traditional Planning and Development Artifacts

Business Specification
Architecture Specification, Test Plan
Design Specification, Test Specification, UI Design Specification
Technical Specification
Software

These artifacts start at the abstract and grow their way down to the detailed documents at 2 and 4 and finally it becomes software. Agile development recognizes the faults of the above and instead uses tools such as User Stories and BDD (Behavior Driven Development) to greatly reduce the investment of time spent on bullets 2-4 so we can get to bullet 5 as soon as possible and get feedback on the working software and working designs. However many new adopters of BDD fall into a trap from their past work experiences/habits around bullet 4—technical specifications, and lose the value of specifying by behavior and instead become TECHNICAL SPEC driven.

When this happens:

high-level (strategic) thinking is reduced
Specifying in the plan ONE technical solution when MANY will satisfy the business requirement anchors EVERYONE (developers, testers, managers, stakeholders, product owners)
the development team will anchored to that technical solution even in light of knowing there are other solutions
the product owner (or source of technical specifications) is anchored to a technical solution and maybe SELLING that solution to stake holders, anchoring them.
stake holders are communicating with the product owner and team using words of a technical solution
if anyone involved sees alternative solutions, they recognize it will be an uphill battle to break the momentum of thought, planning, and development around the technical solution
source of the business requirements (stakeholders, Product Owners) are making technical decisions and spending more time than necessary rather than leaving that to the testers, developers, architects, UI designers. that the technical people will want change with their involvement.

People can’t be agile if they plan like everyone’s minds are made up

So instead of writing your BDD scenarios like this:

Implementation Specific.

Take a few steps back and do this:

Specifies only behavior

During the Sprint Planning the team needs enough of a sense of bullets 2-4 (see Traditional Planning and Development Artifacts) to estimate in Story Points. They have many implementation ideas and discuss a few with the product owner to get a sense of which type of solutions will be acceptable in the given time, resources, and technical capabilities. During the Sprint, the team (or the Pair doing Pair Programming) work out the details on selecting and implementing a solution, and get further details and feedback from the Product Owner as needed.

Let’s Play Am I BEHAVIORAL or NOT?

You remember “Am I Hot or Not?” where you browse through images and decide what’s hot? Well then you’ll LOVE Am I BEHAVIORAL or Not? (Thanks go to Chua Wilkenson for the great idea.)

Add Your own!

Feature coming soon.

WANT TO LEARN MORE?

I’m putting together a BDD training series, some of it is free such as podcasts, videos, and blog articles like this one sent straight to your email box, and some of it is for a small fee for books and online training products. Go here to opt in to receive periodic emails. Otherwise, enjoy the site.

Further Recommended Information

Introducing BDD by Dan North

Well Written BEHAVIOR Driven Development Scenarios

Behavior Driven Development Slide Share by Liz Keogh