What documentation is required for behavior-driven development?

Question

I have been asked to provide some behavior-driven development documents for a project which has not yet started. This leaves me thinking, "other than stories yet to be written, what documents are there?"

So, what documents can I provide which are input to a project in order to structure it, prior to the work actually beginning?

Answer 1

Input Artifacts for Behavior-Driven Development (BDD)

For successful behavior-driven development, you need (mostly) the same documents you'd need for any other agile project, with the addition of executable tests for the business use cases. Some examples include:

• User stories or project backlog items that meet INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
• A prioritized product backlog or input queue.
• A description of the product's expected behavior written relatively natural language using the business domain's standard glossary.
• Behavior that can be expressed in an executable format such as Cucumber's Gherkin parser or similar tool.

The main point of BDD is that you're expressing the expected behavior of your product or application (not its implementation details!) in a way that's executable, testable, and largely self-documenting, rather than compiling a list of detailed specifications in a "it shall or shall not" format.

BDD is Rarely About Specifying Implementation Details

BDD focuses on setting goals or expectations, not implementation-level details. While it can sometimes be hard to differentiate between a specification and a functional or non-functional requirement, as long as you focus on what the system or product should do rather than how is does it, then you're generally on the right track.

However, this is a complex subject, and is somewhat of an art form. There are many books on the subject of behavior-driven development, and The Cucumber Book is a reasonable place to start if you're focused more on how to build good BDD tests, while other books with a business-domain focus may be more useful to stakeholders and executives.

Your mileage will (unfortunately) vary a lot in how you come to grips with BDD, but this should definitely get you pointed in the right direction. If you have more specific questions about particular aspects of BDD from a project management standpoint, then I'd definitely encourage you to open addition questions with more context about the actual problems you're facing with implementing BDD for your project.