How deeply does BDD in Action, Second Edition cover feature mapping?

Works through a card-based workshop procedure from an opening example to steps, consequences, alternate flows, and recorded uncertainty.

Feature mapping in BDD in Action, Second Edition

Feature mapping is a collaborative requirements technique for exploring and organizing a software feature's behavior, flows, variations, and examples.

A requirement such as “let travelers change a booking online” sounds clear until the team asks what happens when the new flight costs more or has no seats. Feature mapping gives business and delivery team members a shared way to explore those questions before work starts. It turns concrete examples into visible steps, expected outcomes, business rules, and unanswered questions. section 6.5 section 6.5.1

Build the map together:

Start with a feature or User Story. Have the product owner tell one concrete, end-to-end story of a user achieving a goal; it need not cover every case. section 6.5.1
Record the example, then break it into steps. A step might be an input, a precondition, a user action, or a point in a workflow. Finish with at least one consequence: the outcome the user should get. section 6.5.2
At each step, ask, “What else could happen here?” Add alternative flows, examples, and relevant business rules rather than assuming the first journey is the whole requirement. section 6.5.4
Group related flows when the map grows, and record unresolved assumptions as questions for follow-up. section 6.5.5

Table 6.2 The various types of cards used in Feature Mapping (view table figure)

Card	Description	Color
User story	The feature or User Story under discussion. Feature Mapping works well for both high-level requirements (at the feature or epic level) and for more detailed ones.	Yellow
Business rule	Constraints or known acceptance criteria related to the User Story.	Blue
Example	Concrete examples and counterexamples of the business rule.	Green
Step	Each example is broken up into steps, which go on yellow cards. Steps can represent tasks or actions a user performs, but also preconditions or input values.	Yellow
Consequence	The last step or steps of an example represent the expected outcome or result. We often mark consequence cards with an arrow at the top.	Mauve
Question	Uncertainty or assumptions that cannot be answered or confirmed during the session.	Pink

The card guide distinguishes the feature, business rules, examples, steps, consequences, and questions. Colors make a map easier to scan, but they are conventions, not requirements. section 6.5

Changing a flight

A traveler moves a booking to Wednesday in the same price category. The expected consequence is an updated booking with no additional charge. Now ask what happens if the new date has no available seats. Mapping that variation exposes different possible outcomes: a refund for a traveler who is not a frequent-flyer member, or a choice between a refund and equivalent points credit for a member. section 6.5.1 section 6.5.2 section 6.5.4

Use feature mapping when journeys, workflows, or data flows need more detail than a quick inventory of rules and examples. A map can cover a focused User Story or a larger feature; its flows can later inform more precise acceptance criteria. section 6.5.5 section 6.4.5

How BDD in Action, Second Edition covers it

Related concepts

This explainer was generated by Manning's knowledge graph from the text of BDD in Action, Second Edition. The section links point to the parts of the book it draws on.