Monthly Archives: November 2013

Behavior Driven Development (BDD): Value Through Collaboration (Part 3: Scenarios)

This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.

Scenarios

The previous post explained narrative as a format to describe feature or requirement. Even though narratives can be written by anyone, it is often the result of conversations between the product owner or the business analyst and business stakeholder.

Scenarios describe interactions between user roles and the system. They are written in plain language with minimal technical details so that all stakeholders (customer, developers, testers, designers, marketing managers, etc) can have a common base for use in discussions, development, and testing.

Scenarios are the acceptance criteria of the narrative. They represent the definition of done. Once all scenarios have been implemented, the story is considered finished. Scenarios can be written by anyone, with testers leading the effort.

The whole process should be iterative within the sprint; as the development of the BDD story progresses, new scenarios can be written to cover cases not thought of before. The initial set of scenarios should cover the “happy path”. Alternative paths should be added progressively during the duration of the sprint.

Continue reading →

Behavior Driven Development (BDD): Value Through Collaboration (Part 2: Narrative)

Narrative

“User stories are a promise for a conversation” (Ron Jeffries)

A BDD story consists of a narrative and one or more scenarios. A narrative is a short, simple description of a feature told from the perspective of a person or role that requires the new functionality. The intention of the narrative is NOT to provide a complete description of what is to be developed but to provide a basis for communication between all interested parties (business, analysts, developers, testers, etc.) The narrative shifts the focus from writing features to discussing them.

Even though it is usually very short, it tries to answer three basic questions that are often overlooked in traditional requirements. What is the benefit or value that should be produced (In order to)? Who needs it (As a)? And what is a feature or goal (I want to)? With those questions answered, the team can start defining the best solution in collaboration with the stakeholders. The narrative is further defined through scenarios that provide a definition of done, and acceptance criteria that confirm that narrative that was developed fulfills expectations.

Continue reading →

This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.

Introduction

The goal of software projects is to deliver value to stakeholders. Even though that might sound an obvious statement, it can be easily forgotten in traditional Waterfall projects. The very nature of the Waterfall process fosters the creation of different departments whose job is to receive work from the previous stage, produce something, and pass it on.

A simplified Waterfall model would be:

Requirements specification resulting in requirements document
Design resulting in software architecture document
Development resulting in actual software
Integration
Testing
Installation
Maintenance

Each of these phases tends to have separate teams and departments. BAs work with requirements, architects write design documents, developers code, integration engineers integrate, testers test, and someone installs the software. Each of these departments is waiting for others to produce something, to start working on their artifacts and, once finished, to pass it on to someone else. The value for the stakeholders is, in many cases, unknown or forgotten. Most people involved in such projects are concerned about “doing their part” and throw it “over the wall” to those coming next. Moreover, artifacts produced by one team are often not used or understood by another.

Continue reading →