BDD 1 teaches teams how to identify a specific scenario, write a specification for it, and then use it to drive implementation. However, teams rarely deal with just one scenario in isolation.
In general, an event that occurs under one set of conditions is likely to occur under many others as well. It’s important to identify the full list of conditions that need to be addressed—and also which sets of conditions will be deferred, deprioritized, or deliberately excluded.
One challenge is surfacing all of these possibilities. Teams struggle with this, especially since most business stakeholders don’t see the full complexity of potential requirements—they tend to focus on their own functional areas. As a result, they often don’t provide the rich requirements needed to address all relevant concerns.
For example, a single scenario might need input from many different perspectives—e.g., UX, Security, Legal, Finance, and Performance. Each stakeholder group may raise scenarios that others wouldn’t consider.
These stakeholders may also have conflicting expectations about what the system should do in the same situation. Resolving those conflicts and integrating the various perspectives is a key part of compiling a complete requirement for the scenario.
This course teaches the team and Product Owner the skills required to surface these perspectives so they can be addressed with the right stakeholders—or explicitly deprioritized. It also teaches them how to reconcile differing views on the same scenario.
The result is more complete and coherent definitions of requirements before coding starts.
Additionally, failing to identify these “other” scenarios is often the root cause of both missed scope and scope creep. This course gives teams the techniques to address the underlying scoping problem. As a result, a powerful side effect is reduced incidence of missed scope and scope creep.
Recommended Program
The best way to up your team’s BDD game is with a combination of live, expert-led training and coaching. We recommend our BDD 2 program, which includes a 2-day course and 3 days of follow-up coaching designed to help your team apply BDD 2 techniques to their real work in a structured, hands-on way.
Course
This 2-day course teaches the next level of BDD skills, expanding the existing BDD analysis & handoff loop to include several advanced analysis techniques. These techniques help ensure a much richer and more resilient set of requirements by the time a PBI reaches maturity.
Topics covered include:
- Using a BDD spec as a concrete analysis artifact
- “What if?” analysis (open brainstorming)
- Critical aspects analysis
- Stakeholder enumeration analysis
- Permutations analysis
- Misinterpretations analysis
The course is interspersed with real-world examples and practical exercises to help teams internalize and apply each analysis technique effectively.
Coaching
After the course, we provide 3 days of coaching to help teams apply what they’ve learned to their own BDD specifications. These sessions are distributed across two to three Sprints, depending on the team’s cadence and availability.
The coaching is hands-on and embedded into the team’s regular refinement and analysis work. The coach observes the team as they apply BDD 2 techniques to real work items, offering guidance, asking questions, and modeling best practices when needed.
Initially, the coach may lead by example—driving the analysis sessions directly. Over time, they shift into a support role, helping team members take the lead while continuing to offer feedback and clarification as needed.
Benefits
BDD 1 gave the team the ability to create a clear, concise, shared understanding between Product and Engineering. However, it did not offer a rigorous framework for exploring or analyzing scope. Identifying related scenarios or stakeholders was left to chance. And there was no structured approach to ensuring that each specification was sound. Superfluous details often remained, and ambiguity persisted.
This level of Behavior-Driven Development introduces a repeatable framework for hardening specifications—eliminating potential misunderstandings, noncritical aspects, and hidden assumptions. It also enables deeper exploration of requirements to uncover hidden scope. Capturing critical business knowledge, such as a list of stakeholders to consult, ensures that vital perspectives are never missed.
This program delivers a “taste of analysis”—a small but powerful set of techniques that are easy to adopt, low-effort, and high-impact. They help teams uncover hidden scope and ambiguity, and build more complete requirements in less time. Just as importantly, they allow teams to experience the value of analysis firsthand—often sparking an appetite for more.
In short, it will help your team miss less and do it faster.
Costs
There are a number of components to take into account when considering the cost of this program:
- Impact on capacity
- Time to proficiency
- Risks
Impact on Capacity
This program will affect capacity during both training and coaching, but the impact is not equivalent to unproductive time.
The team will not deliver anything during the 2-day course. However, the 3 days of coaching are spent applying BDD 2 techniques to real PBIs. While this analysis work requires a time investment, it directly improves the team’s understanding of scope and reduces the likelihood of rework or missed requirements later in the process.
Teams are encouraged to create explicit analysis work items to represent and track this time. This makes the capacity impact visible and ensures it is planned alongside other delivery work.
Most of the work done as part of BDD 2 is real product work—made visible, structured, and deliberate. That said, there will be a modest additional overhead due to discussion, exploration, and coaching. As the team becomes proficient, this impact naturally diminishes and eventually disappears.
You should plan for a 2-day loss of productivity in the Sprint containing the training and an additional 3 days of effort allocated to analysis activities over subsequent Sprints. Total impact is approximately 5 days of focused team capacity—but much of that capacity is spent doing real, high-value work.
Time to Proficiency
Teams typically remain in the “practicing” phase of adoption for four to six weeks. However, because the coaching is distributed across multiple Sprints and integrated into live PBIs, much of that practice happens with expert support.
This delivery rhythm accelerates learning by letting teams apply the techniques in realistic settings while receiving immediate feedback. As a result, most teams are able to internalize the core BDD 2 analysis techniques and begin using them independently by the end of the coaching cycle.
Risks
One key risk is that the team will begin surfacing much more potential scope earlier in the process. The Product Owner (or equivalent) will need time to evaluate which scenarios are in scope, which are not, and which stakeholders to engage.
Another risk is perception: as scope becomes clearer, it may appear that progress is slower. In reality, the work that was previously implicit—only emerging late in development—is now being handled earlier in the maturation process. This surge of “extra” work will even out over time, and ultimately lead to less churn as teams gain the ability to explicitly descope low-priority scenarios.
You should plan for some early delays and for teams to invest more effort in analysis while working through this initial surge of previously hidden scope.
Prerequisites & Enablers
Prerequisite: Program: BDD 1 – Behavioral Writing
BDD 1 is a prerequisite for this program. BDD 2 builds directly on the skills and artifacts introduced in BDD 1—most importantly, the ability to write behavioral specifications in a shared, structured language.
Where BDD 1 focuses on writing scenarios, BDD 2 focuses on analyzing them. It equips teams with techniques to validate, refine, and deepen their understanding of scope—so that behavioral requirements are not only clear, but complete and internally consistent.
Recommended: Program: RMF 2 – Delivering Certainty through Bespoke Completion Criteria
RMF 2 complements this program by giving behavioral specifications real consequence in your process. Once scenarios are formally used as definitions of done, the quality of those scenarios becomes critical. BDD 2 provides teams with the analysis tools needed to meet that standard and avoid rework.
💡 Note: RMF 3 is not a prerequisite for BDD 2, but teams may choose to include BDD 2 analysis techniques as part of their Definition of Ready. This can strengthen scenario quality and support more confident implementation—but RMF 3 also includes readiness criteria beyond BDD scenario quality, such as team capacity, tooling, and external dependencies.
Related Programs:
- Program: PKB-Driven Development (PKBDD) 1
- Ensures that behavioral specifications—alongside other requirements—are stored in a structured, version-controlled Product Knowledgebase (PKB).
- Provides traceability and permanence for the scenarios you analyze in this program, making BDD more maintainable over time.
