Agile development has transformed the software industry by delivering better products faster, but there are still many areas for improvement. Behavior-driven development, or BDD, is designed to close some of these gaps by enhancing communication between business and technical teams. By streamlining communication and eliminating misunderstandings, BDD enables developers to improve product quality and move even faster. Let’s take a look at some of the challenges associated with conventional user stories and how BDD techniques like example mapping and event storming can overcome them.

Challenges with User Stories

Agile development places a heavy focus on user stories, which shift the focus from writing technical requirements to having actual conversations. Acceptance criteria help translate the user story into a set of requirements that must be met to mark it complete. User stories are a great way to improve communication between business and technical teams, but they aren’t without problems of their own:

• Business Focus: User stories are focused on user personas and what they are trying to achieve rather than business goals.

• Accountability: User stories are fleeting in nature, and nobody is responsible for owning the specification and keeping it up-to-date.

• Quality Varies: Acceptance criteria are often ad-hoc and vary in quality, and there’s no way to easily trace them back to a user story.

There are also issues with the processes used to convert user stories and acceptance criteria into code. For example, many Agile developers use test-driven development (TDD) when converting acceptance criteria into a code, but the bottom-up approach introduces some problems. Namely, TDD produces a lot of low-level tests without having a high-level test that proves the feature delivers on the promised functionality.

Example Mapping

Behavior-driven development introduces concrete examples to address these concerns and eliminate any ambiguity about a feature. In addition to ensuring everyone is on the same page, these examples help uncover potential gaps that nobody considered at the onset and facilitate conversations about missing or assumed functionality. These concrete examples are the result of deliberate discovery meetings among product, development, and testing team members. Example mapping was developed by Matt Wynne and published in a December 2015 Cucumber blog post. After encountering long, unstructured, and boring deliberate discovery meetings, Matt came up with a low-tech method for making these conversations shorter and more efficient. Example mapping uses index cards and pens to capture user stories, acceptance criteria, examples, and questions in quick, structured meetings. The process works best with three amigos teams, consisting of a product manager, software developer, and test engineer, working on a single user story over the course of about 25 minutes. The process involves four simple steps:

1. 1. User Story: Start by writing the user story on a yellow index card and placing it at the top of the table.
   2. Acceptance Criteria: Write each acceptance criteria on a blue index card and place those across the table under the yellow story card.
   3. Examples: Brainstorm examples of each acceptance criteria, write them on green index cards, and place them under the acceptance criteria card.
   4. Questions: If any question arises during the conversation, write those on red index cards and move on with the conversation.

[caption id="attachment_4819" align="alignnone" width="1007"] Example Mapping Layout - Source: Cucumber Blog[/caption] Shortly before the time is up, it’s important to step back and ask a few questions:

• Are there too many red index cards on the table? If so, you may still have a lot more to learn about the user story before moving it into development.

• Are there too many blue index cards on the table? If so, the user story should be broken down into multiple user stories to reduce complexity.
• Are there too many green index cards on the table? If so, the acceptance criteria should be broken down into multiples rules to reduce complexity.

The final step is taking a quick vote to see if the user story goes into production or goes back to the drawing board for some modification.

Event Storming

The concrete examples from example mapping are great for developing executable specifications, but what about modeling the higher level application architecture? Event storming was developed by Alberto Brandolini, which he introduced in a November 2013 blog post. The process focuses on identifying domain events, or anything that happens that is of interest to domain experts. Since its introduction, event storming has evolved to include a lot of different moving parts, but the most important components are domain events (business actions), user commands (user input), and aggregates (application’s response). There are five basic steps involved in event storming:

1. 1. Invite Team Members: Event storming works best with six to eight people, including members of both business and technical teams.
   2. Provide Modeling Space: Ensure that there’s enough space available to model the problem by replacing a whiteboard with an IKEA paper roll or another medium.
   3. Explore the Domain: Brainstorm domain events, or meaningful events that happened in the business, and place them all on the modeling surface. For example, a domain event might be something like a product having been purchased, or an account having been locked after an invalid password attempt was made.
   4. Explore the Origins: Identify user-initiated commands that sparked these domain events. For example, a user might have entered their credit card details or attempted a login with the wrong password. In Gherkin, these are the When portion of the Given-When-Then statement.
   5. Look for Aggregates: Identify ways that the application should respond to domain events and user commands. For example, the payment is processed, or the account status switches to locked. In Gherkin, these are the Then portion of the Given-When-Then statement.

By writing and organizing these processes, it’s much easier for everyone to understand the domain logic and ultimately choose the best application model. The full process is beyond the scope of this blog post, but it is fully outlined in the book Event Storming by Alberto Brandolini, as well as discussed in various training workshops.

The Bottom Line

Example mapping and event storming are both actionable strategies to get business and technical teams on the same page, making them integral parts of behavior-driven development. HipTest makes behavior-driven development easier to implement by providing a common interface for business and technical teams. In addition, the platform integrates with automated testing and continuous integration frameworks to build a living documentation of an application’s features. Sign up today for a free trial or demo.