The chapter follows a delivery team as they turn a newly prioritized story into readable BDD scenarios, showing how discovery examples become more polished specifications during formulation. It emphasizes that writing scenarios is not just transcription: the team must choose which examples matter, clarify the intended rule, and shape the language so it is understandable to business and technical readers alike. A recurring theme is that the best scenarios are concise, unambiguous, and centered on the behavior that matters most.
The discussion also explains that formulation is usually better handled by a small subset of the team, often in pairs, rather than by everyone at once. This keeps the work efficient and gives others time to review asynchronously, but only if that review is taken seriously and completed before implementation begins. Product owners remain accountable for the specification, while developers and testers benefit from helping shape the scenarios because it deepens their understanding of the business context and shared terminology.
Much of the chapter is devoted to readability improvements: avoiding unnecessary quotation marks, preferring third person over “I,” using pronouns only when they remain clear, and being cautious with Background because it can hide important context and reduce maintainability. It also encourages omitting context that is safely implicit, merging or discarding examples that don’t really illustrate the target rule, and using comments or text descriptions sparingly. Finally, it shows that scenarios can evolve incrementally, that some may remain manual when automation would be premature, and that formulation generally becomes faster as the team develops a consistent style and better understanding of the domain.
Tasks and activities in the BDD approach
Restricting customers using a blocklist
Restricted customer - unauthenticated
E-mail or phone match examples
Question cards
Restrictions are independent of authentication status examples
Upload replacement blocklist
Summary
Start writing a scenario from the expected outcome, and work your way back to the essential context
Don’t involve the whole team in formulating scenarios, but ensure that the whole team reviews every scenario formulated
Scenarios need to be unambiguous, so be specific about every actor’s role
Scenarios need to be readable, so use idiomatic natural language avoiding things like unnecessary repetition and technical details
The Gherkin Background keyword should be avoided
Try to write your scenarios so that you don’t need Gherkin Comments or Text Descriptions
Honor the intention of the examples uncovered during discovery, but refine them during formulation to be idiomatic natural language, adhering to the BRIEF principles
As new requirements are uncovered, some existing scenarios may need to change. Incremental specifications allow us to iteratively and incrementally deliver the system
Most scenarios should be automated. Those that have not been automated need to be manually reviewed regularly for continued correctness
FAQ
What is the main goal of writing scenarios in chapter 9?The main goal is to turn discovered examples into clear, business-readable scenarios that illustrate the rule the system should follow. The chapter emphasizes readability, shared understanding, and creating scenarios that can later be automated and reviewed by the team.Why does the chapter recommend “writing it upwards” when formulating a scenario?“Writing it upwards” means starting with the expected outcome and working backward to the context. This helps ensure each part of the scenario has a clear causal connection and makes it easier to remove unnecessary context statements.Who should formulate scenarios: the whole team or a smaller group?The chapter recommends that formulation be done by a smaller subset of the delivery team for efficiency, while the whole team remains responsible for reviewing and accepting the scenarios. This balances speed with collective ownership.Why shouldn’t formulation usually happen during the discovery session?Discovery is meant to uncover misunderstandings and assumptions quickly, while formulation is more reflective and detailed. Combining them slows the team down and reduces engagement, so they are treated as separate practices.Why does the chapter discourage using quotation marks in scenarios?Quotation marks are often unnecessary and can reduce readability. They may also influence generated automation snippets, but the chapter argues that readability for human readers is more important than convenience for the automation framework.Why should scenarios avoid using “I” as the actor?Using “I” is considered imprecise because the reader may mentally substitute themselves into that role. The chapter recommends writing scenarios in the third person using a clear role or persona so the meaning stays consistent for everyone.When is it acceptable to use repetition or pronouns like “they” in a scenario?If using a pronoun such as “they” does not reduce clarity, it can be a good way to improve natural language flow and reduce repetition. However, if it introduces ambiguity—especially with multiple actors—it should be avoided.Why does the chapter advise against using the Background keyword?The chapter says Background harms readability and maintainability because readers must remember hidden context from the top of the file. It can also create maintenance risks, since changing the Background affects every scenario in the feature file.What should be done with examples that are not fully formulated into scenarios?Unformulated examples may still be useful for clarifying understanding, and some may even become programmer tests. The team can merge examples, simplify them, or decide not to turn them into scenarios if they do not add value to the specification.Why are some scenarios tagged as @manual, and what is the risk of doing that?Scenarios are tagged @manual when they will not be automated, often because the implementation is still uncertain. The risk is that manual scenarios can become outdated without automatic feedback, so they require regular human review to stay relevant.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
Effective Behavior-Driven Development ebook for free
