Behavior-Driven Development for Product Owners


Behavior-Driven Development for Product Owners


water drop ripples

A product owner should always be looking for opportunities to bring value to the customer while simultaneously boosting their team’s efficiency. Acceptance criteria is a vitally important part of the user story, and yet it is sometimes ignored, incomprehensible or overly detailed. The key question to ask is: is the team reading, designing and implementing the code according to the acceptance criteria as well as the product owner’s expectations?

If the answer to that question is “no,” I wouldn’t assume it’s the team’s fault, since there are often better ways for the product owner to drive, clarify and define the acceptance criteria. One of those ways is the 3 “C”s Theory by Ron Jeffries. Another is behavior-driven development, which I’ll be exploring in this post.

The Benefits of BDD

The 3 “C”s Theory is an approach which doesn’t depict the acceptance criteria in too many sentences or words. In a nutshell, the first “C” refers to the card where the user story is written. The second “C” refers to the conversation that takes place when the team begins to collaborate with the product owner and understand how the deliverable will work. Finally, after the user story is implemented and tested, the team passes through the third “C,” which refers to the confirmation of the final result of the user story.

Another method that product owners can use to work with the team to define the acceptance criteria is known as behavior-driven development (BDD). BDD builds upon test-driven development (TDD) by going beyond the development team. In other words, BDD is a technique used to write the acceptance criteria in a way that anyone can read and comprehend. In addition to facilitating communication between a team, their company and its technical stakeholders, this approach has several other benefits:

  1. Allows the product owner to clearly define what is expected from the user story itself.
  2. Creates fewer communication gaps.
  3. Opens communication between the business and the development team by having multiple hands on the deliverable of each user story.
  4. Builds a strong sense of collaboration between the product owner and the development team by removing ambiguous language.
  5. Increases agility and efficiency by turning the outcome of BDD into automated test cases which can be integrated into the continuous delivery pipeline and tool.
  6. More executable documentation and less waste.

BDD was designed by Dan North, author of the book “The RSpec Book: Behavior-Driven Development with RSpec, Cucumber, and Friends” as an evolutionary practice of TDD.

Applying Behavior-Driven Design

In order to apply BDD, I would recommend following this five-step flow:

  1. Identify and define the user stories.
  2. Refine the acceptance criteria.
  3. Implement the code using TDD.
  4. Demonstrate the user story.
  5. Automate the acceptance tests through the continuous integration pipeline.

I will be focusing on the acceptance criteria where BDD is initially applied, but the five-step flow can give you an idea of how it can be applied to the entire life cycle.

Define User Stories

The user stories are first created by the product owner and then refined in either a workshop or a product backlog grooming session before the sprint planning. In both cases, a multifunctional team, product owner and technical stakeholder are required.

Some preliminary questions should be asked in order to form examples of utilization or business case scenarios which can help the team to better understand what has been discussed.

Suppose that a potential buyer goes to an e-commerce website and, after searching for a product, he or she receives a message that the product is currently unavailable. How can the  website retain that customer? To find out, let’s go ahead and write a user story, then ask a few questions that might come up during the subsequent meeting.

User story:

“As a customer, I want to be notified via email whenever the product is available again.”

Some questions that might be raised are:

  • Does the user have to own a site account in order to be notified? If so, what happens when the user is not logged in?
  • What happens if the user already created an alert for the same product?

After answering those questions, the team will have a better understanding of what the product owner is expecting from the user story. Next, the team can collaborate with the product owner to write the acceptance criteria with as little ambiguity as possible. For example:

  • User has to own a site account; otherwise, redirect the user to the registration page.
  • User has to be signed in; otherwise, redirect the user to the login page.
  • Users who are registered and signed in must confirm their email address.

Refine the Acceptance Criteria

The next step is organizing the acceptance criteria in the format required by the BDD framework. There are several BDD frameworks, including FIT, FitNesse, Cucumber, Concordian, Robot Framework, RSpec, Jnario and more. For our example, I’ll be using Cucumber: 

cucumber language acceptance criteria

In this case, I used Gherkin, which is the language that Cucumber understands. It is a business readable, domain specific language that lets us describe software behavior without detailing how that behavior is implemented. Gherkin is primarily used for two purposes: documentation and automated tests. The product owner should write the acceptance criteria in Gherkin for each user story.

In summary, every scenario contains the following keywords: Given, When, Then, But and And. Another useful keyword is Examples where you can outline rows with different values for each attribute. You can also use Data Tables to pass a list of values. Learn more from the reference guide for Gherkin

Implement the Code Using TDD

Next, the development team comes into the picture to start implementing the code while applying TDD in order to pass all acceptance tests.

Demonstrate the Acceptance Tests Results

After all successful tests, the user story is validated by the product owner and is often shown in a sprint review or showcase.

This phase shouldn’t be a major concern for the team, due to the fact that the development team will have followed the acceptance criteria written in BDD by the product owner.

Automate the Acceptance Tests Through the Continuous Integration Pipeline

Finally, it’s time to include the acceptance tests in the continuous integration tool and make them run automatically for each commit and build. That’s where the fun starts, and there is no need to validate the test cases manually.

BDD in Summary

Behavior-driven development is a very pragmatic approach which offers a number of advantages, the most significant of which is the ability to share a clear understanding of each new user story and what will be delivered.

When used properly, it creates less rework and waste, more agility, a higher level of collaboration, common understanding and more productive teams. In fact, the product owner can use BDD to produce executable documentation that will be reused all over the development code, thereby bringing more value to the team and delivery pipeline.

If something is not clear or you would like to learn more about BDD, please feel free to ask a question or share your thoughts in the comments section below.



 

Paulo Rebelo helps companies to improve using agile and lean principles and methods like Scrum, XP and Kanban. He currently works at Blackhawk Network in the U.S.

Learn More
comments powered by Disqus