4 Who does what and when
Behavior-Driven Development is presented as a set of connected activities that turn a user story into a working, releasable increment through collaboration, examples, and automated feedback. The chapter emphasizes that there is no single universal workflow: teams should adapt the process to their context, culture, and delivery model. Rather than treating the described activities as rigid best practices, the book frames them as a practical sequence that helps teams understand requirements, align on behavior, and keep learning as implementation progresses.
The core BDD flow starts with selecting a user story, then running requirement workshops to explore rules and examples, formulating those examples into business-readable scenarios, reviewing them with business representatives, automating them as failing executable tests, implementing the application code to make them pass, and adding supplementary testing and release activities as needed. Responsibility is shared across roles: product owners and stakeholders help shape and validate the story, the whole team contributes during discovery, developers and testers often pair on formulation and automation, and testers coordinate additional testing. The chapter also stresses that scenarios should be concise, readable, and interesting enough that business colleagues actually want to review them.
The chapter then shows how this approach fits into different delivery environments. In Scrum, BDD works naturally with regular refinement and planning meetings, and Example Mapping helps structure conversations and shorten meetings by focusing on concrete examples. In Kanban, BDD fits as a story-centered sub-workflow that can be visualized alongside other work, while distributed teams can still use the same process if they rely on strong collaboration tools and shared notes. For fixed-scope and regulated projects, BDD helps transform specifications into living documentation, making assumptions, decisions, test coverage, and execution evidence explicit and easier to maintain, which improves traceability, acceptance, and compliance.
High level BDD approach showing the progress from user story to working application using green arrows and the inclusion of learning gained during using blue arrows
Tasks and activities in the BDD approach
Example map in Google Sheets
Example map in mind map form
Example map in the form of hierarchical notes
Summary
- BDD is an approach consisting of eight distinct activities that should be applied in order.
- BDD works well with Scrum and other agile methodologies.
- Using BDD across a distributed teams is possible, but thought needs to be given to enabling clear communication.
- Fixed scope projects don’t fit well with Agile, but BDD can help with determining the detailed requirements.
- BDD is welcomed in regulated environments.
FAQ
What are the main activities in the BDD approach?
The BDD approach typically includes these activities: pick a user story, run a requirement workshop, formulate examples into scenarios, review the scenarios, automate them, implement the application, perform supplementary testing, and release a potentially shippable increment.
Who should participate in a requirement workshop?
All relevant roles should be represented in the requirement workshop, at least the “three amigos.” This usually includes business and delivery perspectives so the team can discuss rules and examples together and refine the story effectively.
When should a user story be picked for BDD work?
A user story should be picked before the requirement workshop, preferably at least a day in advance. This gives the team time to prepare and arrive with enough context to discuss the story meaningfully.
Who is responsible for formulating scenarios?
Initially, formulation is best done with the entire team while the wording and style are still being established. Later, it can be done efficiently by a developer or automation-focused person paired with a tester or quality-focused person, with review by a business representative.
When should scenarios be automated in BDD?
Scenarios should be automated before implementation starts, following a test-driven approach. In some teams, automation is done later, but that reduces the benefits of BDD and should not become the default.
Who usually automates the scenarios?
Developers or test automation experts typically automate scenarios. In pair programming, pairing a developer with a tester often works well. The exact split depends on company culture, team setup, and the complexity of the automation infrastructure.
Who implements the application code in the BDD workflow?
Developers implement the application code. They start as soon as the first scenario has been automated, using failing scenarios to drive the implementation in a Red/Green/Refactor style.
What is the purpose of reviewing scenarios?
Reviewing scenarios ensures they correctly describe the expected business behavior. The product owner, and sometimes business analysts, customers, or key stakeholders, check that the scenarios use appropriate business terminology and reflect the real requirements.
How does BDD fit into Scrum?
BDD fits well into Scrum by using regular refinement and planning meetings to explore stories through examples. Formulation is often added to the implementation pipeline, and tasks can be aligned to scenarios to improve progress visibility and feedback during the sprint.
Why is BDD useful for distributed, fixed-scope, and regulated projects?
In distributed teams, BDD provides concrete examples and shared notes that improve communication. In fixed-scope projects, it turns static specifications into living documentation with explicit decisions. In regulated environments, it supports traceability by combining specifications, tests, and execution evidence in a business-readable form.
Effective Behavior-Driven Development ebook for free
