Before you go, check out these stories!

Hackernoon logoHow To Incorporate Behaviour Driven Development in Acceptance Criteria? by@fmrigueiro

How To Incorporate Behaviour Driven Development in Acceptance Criteria?

Author profile picture

@fmrigueiroFilipe Rigueiro

Product Analyst for Digital development and CEO of Uni Data.

How to use behaviour driven development when writing acceptance criteria for user stories

What is behaviour driven development

In software engineering, behaviour-driven development (BDD) is an Agile software development process that encourages collaboration among developers, QA and non-technical or business participants in a software project.

It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development(TDD).

Behaviour-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development

Using BDD to write acceptance criteria for User Stories

Acceptance criteria is an important part of Agile development it helps:

Confirm when the application functions as desiredSynchronises the development team with the customerCreate a basis for testing as a positive or negative outcomePlanning and refinement as all possible scenarios are mapped

Acceptance criteria are:

Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholders.

The most popular way of writing user acceptance criteria is scenario-orientated which is derived from behaviour driven development (BDD).

Writing in the first person (I) ensures you are talking from a user’s perspective and keeping their needs in mind. Creating a focus on the requirements of a feature from a user perspective helps developers create tests and think about user value features and not tickets.

Writing user Acceptance criteria

As a product owner (PO), business analyst (BA) or product analyst (PA), you are required to write acceptance criteria for the user stories on the backlog. This will have an impact on development and QA of the feature.

Well written acceptance criteria can capture business requirements, error states, and limitations of the feature from a business perspective as well as from the user experience.

A common format is to use the Given, When, Then format of Acceptance criteria. This creates a first-person view of the feature that helps the team navigate the software from the viewpoint of the end-user.

Thinking like the end-user can help create scenarios for edge cases, potential errors, and the core of the feature.

The format I usually use in any card on JIRA/YouTrack/ Trello (whatever you prefer) is:

Acceptance Criteria

Scenario : [Description]

Given [Situation / Prerequisite]

When [Action]

Then [Result]

I keep this format as a template and reutilize it in every user story. This creates a consensus for the development team and helps create a discussion of potential scenarios that might occur when using that feature.


How to write acceptance criteria for a user story.

User Story

As a logged-out user
I want to be able to sign in to a website
So that I can access my profile

Acceptance criteria:

Scenario — System user signs in with valid credentials

Given I’m a logged-out system user
and I’m on the Sign-In page
When I fill in the “Username” and “Password” fields with my authentication credentials
and I click the Sign-In button
Then the system validates the details are correct and signs me in

Capturing business rules with acceptance criteria

User Story

As a new user
I want to create an account
So that I can access the app

Acceptance Criteria

Scenario 1 — User creates a unique username

Given I’m creating a new user name
and I’m on the Choose your username
When I fill in the “Username” with an already existing name
Then the system warns me to choose a different user name
and it gives me 3 suggestions based on my input
and the save username button is disabled

Scenario 2 — User uses special characters username

Given I’m creating a new user name
and I’m on the Choose your username
When I fill in the “Username” field with special characters
Then the system warns me to use only alphanumeric characters
and the save username button is disabled

Benefits of behaviour-driven development

Strong collaboration — BDD increases and improves collaboration. It enables everyone involved in the project to easily engage in the product development cycle. And by using plain language, all can write behaviour scenarios, even for edge cases.

High visibility — By using a language understood by all, everyone gets strong visibility into the project’s progression.

The software design follows business value — In fact, BDD puts great importance to the Business value & needs. By setting priorities with the client, based on the value it provides, developers can provide a better result because they have a strong understanding of how the client thinks.

The ubiquitous language — As mentioned earlier, the ubiquitous language is understandable by all the members of the team, which reduces misconceptions and misunderstanding and makes it easier for new members to join the working process.

Software development meets the user need — By focusing on the business’ needs, you get satisfied users, and that implies a happy business of course. Actually with BDD, as its name says it, you focus on the behaviour, which has a stronger impact than the implementation itself.

More confidence from the developer’s side — Teams using BDD is in general much more confident that they won’t break code and have better predictability when it comes to their work.

Lower costs — By improving the quality of the code, you are reducing costs of maintenance and minimising the project’s risks.

Disadvantages of BDD

The only disadvantage of using BDD when developing a product is possible misunderstanding what BDD is and how it is implemented.

Another “disadvantage” is that the interaction with the user is essential to understand the point of view and to understand many different users, so if the user is not available it is difficult to create that behaviour on the feature and write acceptance criteria. The user needs to be well understood and its part of the BA, PA, PM, PO to provide that information and be an expert on the user to avoid ambiguity.


Using behaviour driven development to create acceptance criteria is a great way to improve clarity and collaboration within the team, this improves the quality of the product and removes barriers of communication. Also, it is a great way to focus the team in thinking like a user and building products that users will love.


Join Hacker Noon

Create your free account to unlock your custom reading experience.