Book Club: Behavior Driven Development – Discovery (Chapter 2)

The following is a chapter summary for “BDD Books – Discovery” by Gaspar Nagy and Seb Rose for an online book club.

The book club is a weekly lunchtime meeting of technology professionals. As a group, the book club selects, reads, and discuss books related to our profession. Participants are uplifted via group discussion of foundational principles & novel innovations. Attendees do not need to read the book to participate.

Background on BDD Discovery

DISCOVERY

“Explore behavior using examples

Written by the creator of SpecFlow and the author of The Cucumber for Java Book, this book provides inside information on how to get the most out of the discovery phase of Behaviour Driven Development (BDD). This practical guide demonstrates good collaboration techniques, illustrated by concrete examples.

This book is written for everyone involved in the specification and delivery of software (including product owners, business analysts, developers, and testers). The book starts by explaining the reasons BDD exists in the first place and describes techniques for getting the most out of collaboration between business and delivery team members.

This is the first in the BDD Books series that will guide you through the entire development process, including specific technical practices needed to successfully drive development using collaboratively-authored specifications and living documentation.”

BDD Discovery

Chapter 2

“In this chapter, we are going to peer into the daily work of a software product team to learn more about how they use structured conversations to help them discover what the expected behavior of the next feature should be. We’ll start by describing one of their requirement workshops. This will introduce concepts that you’re not familiar with, but don’t worry, all your questions will be answered later in the chapter.”

Chapter 2 – Structured Conversation

2.1 Where is My Pizza?

The sample used in the book is a Pizza delivery service, with an app that will track the real-time location of order(s). This example will be used throughout the book as the team develops features to modify the delivery address of an order after the order has been submitted.

2.2 A Useful Meeting

The section introduces the idea of a “Requirement Workshop”:

“The team meets regularly (usually several times a week) to discuss the work that they’ll be undertaking in the next sprint or two. The purpose of this meeting is to explore a story, understand it’s scope and illustrate it unambiguously with concrete examples. While they’re doing this, they may discover new details about the story. They may also ask questions that no one at the meeting is able to answer right away.

What matters most in this meeting is to bring diverse perspectives together, so that they can learn about what needs to be done and work together more effectively. In other organizations, similar meetings have been variously called three amigos meeting, discovery workshop, specification workshop, story refinement, product backlog refinement and backlog grooming – as always, the name is less important than the purpose.”

Chapter 2 – A Useful Meeting

Requirement Workshop

• The team meets regularly
• The purpose is to explore a user story
• The scope of the story is discussed
• The story is illustrated with examples
• Questions are documented that no one in the workshop can answer

The team will consider “Change Delivery Address”. The feature will implement the following:

• The system will need to be able to confirm whether it’s possible to change the delivery address
• The system will need to check that the new address is not too far from the current one.
• Determine the state of the order

Throughout the book, the authors demonstrate a technique called Example Mapping to help facilitate requirements workshops. Example Mapping is a way to conduct a structured conversation.

2.3 Collecting Examples

Persona in user-centered design and marketing is a fictional character created to represent a user type that might use a site, brand, or product in a similar way.

An example is written on a green card. Please refers to Figures 7 & 8.

Business Rules are written on blue cards. Only valid address is accepted. Estimated time of arrival is updated or new address should be within restaurant’s delivery range.

Problems or Questions are written on red cards. Please refer to Figure 12.

The team discusses other business rules such as valid address is accepted, estimated time of arrival is updated, and new address is within restaurant’s delivery range. For each rule, one or more examples are used to illustrate those rules. The workshop finishes in a time-box of 30 minutes with the completed Example Map shown in Figure 14. Further details on the content of an Example Map is discussed in Section 2.5.

2.4 Deliberate Discovery

“Discovery that happens while you’re developing software can be thought of as ‘accidental discovery’ – it may upset your schedule, or even derail or interrupt your roadmap entirely. The discovery that happens during a requirement workshop is ‘deliberate discovery.’”

Chapter 2 – Deliberate Discovery

The understanding of the user story is deliberately explored with concrete examples. Otherwise, learning happens accidentally during development of a story. Examples are used both to illustrate what is known and question assumptions.

2.5 Example Mapping in a Nutshell

“Example Mapping is a simple, low-tech method for making conversations short and powerfully productive.”

Matt Wynne

Examples are captured on green cards – illustrate concrete behavior of the system.

Rules are written on blue cards – these are logical groupings of the examples usually focusing on a particular condition. Commonly referred to as acceptance criteria (AC), business rules, or simply requirements.

Questions or assumptions are captured on red cards – any topic that would block the discussion.

User Stories are written on yellow cards – start by discussing a single user story, but as we are digging into the details, we often decide to split the story into smaller stories and postpone some of them.

The User Story is placed on the top row and the rules are arranged in a row underneath. Examples pertaining to a given rule are placed underneath that rule. The red cards are placed to the side of the Example Map. For each session, a facilitator should schedule the meeting and keeps the session active by ensuring discussion is captured on the cards and everyone agrees with the wording.

2.6 How to Establish Structured Conversations

Structured Conversation is a facilitated exchange of ideas that conform to a predefined form.

A structured conversation exhibits the following properties:

• Collaborative – all attendees participate actively
• Diverse Perspectives – all primary areas of a team are represented
• Short – regular workshops in a time-box so the feedback loop is quick
• Progressive Focus – capture the progress of the workshop in real-time
• Consensus – agreed concrete examples measure the workshop’s success

Each property in the structured conversation is elaborated on further below.

Collaborative

• Conversations should involve the entire team
• Establish a culture where everyone can participate

Diverse Perspectives

• Requirement workshops should have representation from different perspectives (development, test, business, UX, etc.)
• The business representatives focus on the fulfillment of the business goals
• The developers explore the technical implications of the feature
• The testers challenge the feasibility of testing the feature and help identify special edge cases

Short

• Requirement Workshops should be no longer than 30 minutes
• Long meetings are exhausting and expensive.
• Short meetings can be scheduled more frequently
• Frequent meetings can vary the attendees to improve shared ownership and can also reduce the impact of unanswerable questions

Progressive Focus

• The workshop has a focus on what will be discussed but not discovered
• Understanding becomes progressively more complete
• Meeting should have a stated purpose
• Understanding should be captured as it develops
• Be able to quickly grasp the state of the discussion
• Stop discussions that aren’t going anywhere

Consensus

• The output is correct
• The feature is sufficiently understood
• There is no hidden or private knowledge
• Who is responsible for answering each remaining question

2.7 What We Just Learned

“Software development is a learning process. The more we can learn about the problem, the easier solving it becomes. This process can be made more effective by having several team members (with different perspectives) analyzing the requirements together before they start developing the software. These collaborative requirement workshops are most productive if they are kept short and run regularly throughout the project – often several times a week.”

Chapter 2 – What We Just Learned

In the next Chapter of the series, we’ll learn how to write concrete Examples.

Series Navigation