Behavior-Driven Development Helps Deliver User-Centric Solutions

The best projects start with the finish line in mind. For development teams, that means asking early on:
How will the customer use the solution once it’s implemented? Behavior-driven development asks that
question upfront—and creates a path for teams to better ensure they’re working toward a solution that
addresses the needs of the end user.

Behavior-driven development starts with one or more conversations between those who are
implementing the solution and the user or customer. Rather than talk strictly requirements, the two sides
often dig into real-life scenarios in order to build a shared understanding around requirements and
context. And those conversations can span both functional and non-functional features, says Nathan
Subramaniam, PMI-PBA, PMP, PgMP, lead business architect at Universal Service Administrative Co.
(USAC) in Washington, D.C., USA.

The most common syntax to write acceptance criteria for user stories is the given-when-then format. Each
acceptance scenario has a three-part structure: the given (the preconditions of the user in the product or
the context of a particular scenario), the when (the triggers that cue action or what actions need to take
place), and the then (how the product should react in these conditions or the expected output).

“This provides consistency, which helps testers define when to begin and end testing of a particular
feature,” he says. “Defining the needed test cases helps ensure the required capability meets the
requirements, and—most importantly—it encourages conversations between the user and the
development team.”

Flexible and Effective

Teams at USAC employ a behavior-driven approach. The organization’s business requirements document
includes a dedicated section for acceptance scenarios, structured as given-when-then statements. Teams
at USAC also use “input, process, output” as common terms. It’s worth noting for newer business analysts
that even when the exact language might vary, the underpinnings remain in place.

The consistency of having acceptance scenario presented in the given-when-then format across initiatives
big and small pays off, Subramaniam says, because teams that use behavior-driven development can
better “avoid going to the end of the iteration and building a feature that doesn’t deliver value.”

Towards the project closure, we ensure a clear linkage among business requirements, acceptance
scenarios, functional requirements, Jira stories, (user acceptance testing (UAT) test plan, and UAT sign-
off. In addition to UAT, and as part of each release, the IT quality control team conducts a complete system
regression test along with volume and performance tests to ensure the system continues to operate as
expected and within the service level agreement requirements.

Although behavior-driven development is more commonly used in an agile environment, it’s a mistake to
assume it doesn’t also work well in a waterfall approach. “The agile approach dramatically enhances the
behavior-driven development process,” says Subramaniam, who has used behavior-driven development
with both types of approaches. “But regardless of the approach used, there’s value to behavior-driven
development.”

Developed by PMI for PMIstandards+™ with contributions from Nathan Subramaniam, PMI-PBA, PMP,
PgMP. ©PROJECT MANAGEMENT INSTITUTE, INC.