Software is made up of behaviors – the ways that the software functions as measured external to the code.
It makes sense for organizations to treat behaviors as the fundamental unit of software, using them in or as a driver for the following activities, to name a few:- Defining requirements
- Communicating requirements
- Testing
- Coding
- Creating documentation
- UX design
- UI design
- Validating work
Behavior-Driven Development (BDD) is a platform for doing just that. BDD allows a team to break their work down into behaviors and meticulously define each such behavior using the Gherkin syntax (a.k.a. “given-when-then”).
BDD is a big discipline, with many things to learn and it can take a team a long time to adopt all of it. However, like any big skills set, it can be broken down into smaller pieces.
BDD 1 outlines the core aspects of using BDD to define requirements and hand them off between Product and Engineering.
Recommended Program
The best way to kick-start your team’s journey to BDD is with a combination of live, expert-led training and coaching. We recommend our BDD 1 program, which includes a 1-day course and 3 days of follow-up coaching so the expert can help your team apply this technique to their real work.
Course
This 1-day course covers the basics of Behavior-Driven Development along with all the requisite skills to make it work. It has enough interactive exercises to ensure learners engage in the practice required to make it stick.
Topics covered include:- Intro
- What is a behavior?
- Scenarios
- Anatomy of a behavior
- Gherkin syntax
- Relationship with testing
- Core handoff/requirements definition loop
- Conclusion/Summary
The course is interspersed with plenty of examples and exercises to help cement the ideas and practices in the learner’s mind.
Coaching
Afterward, a recommended 5-day coaching package, split across two Sprints, helps learners implement what they learned in their real context using real PBIs. This is usually distributed between two Sprints such that there are three days of coaching in the first Sprint and two in the second. In the sessions, the coach will lead the team through the process of applying BDD to their real PBIs. The output of the sessions will be (a) comfort applying the BDD 1 techniques and (b) a set of PBIs that have been transformed into BDD-enhanced PBIs.
Benefits
This level of Behavior-Driven Development is just the first step but, still, the impact is huge. The primary visible effects will be that the team will have less ambiguity in their requirements, fewer misunderstandings of requirements, and a clearer scope around what actually needs to be done for any given work item.
This will manifest in two important ways:- That team will have less rework, which usually comes from people building the wrong thing as a result of a misunderstanding or miscommunication.
- The team will also have less extra work, which usually comes from the team and stakeholders not understanding the true scope of work and trying to be “safe” rather than “sorry”.
The team will probably also be happier and less tense as a result of greater certainty in what they’re delivering.
In addition, the team will likely create better estimates and be more confident in their estimates because the estimates are being made in light of far better understanding than before adopting BDD.
Furthermore, there are several beneficial side effects from this level of BDD:- The team will get all the tests (manual) they need out of the process, practically for free.
- The ability to make explicit decisions on what is not needed now, and delay scope as needed has a direct impact on an organization’s ability to be Agile.
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 will significantly impact capacity during training and immediately after. The team will not be able to deliver anything during the 1-day course and is likely to deliver at 50% capacity during the three days of coaching thereafter. Therefore, when planning costs, you should consider a 3-day loss of productivity in the first Sprint directly related to the training & coaching activities. For the same reason, a 1-day loss of productivity should be accounted for in the Sprint immediately after delivery. This brings the total impact on productivity to a 4-day capacity loss.
Time to Proficiency
The time to realize this level of BDD is actually quite quick. You can expect your team(s) to stay in the “practicing” phase of adoption for four weeks.
Risks
Product Owners – especially those who have a primarily project-management-oriented background – may be worried that they are being asked to do a lot more work. This can be mitigated by making sure the team is involved.
Some of this is them mistaking the cost of learning for the cost of doing. However, a lot of it is just that the level of detail that is required from a PO when a team is using BDD is far greater than that required of a PO that focuses on the “user story format” for requirements.
An investment will need to be made in adjusting the expectations of these POs. Some are simply unable or unwilling to make the transition and the organization will have to decide what the best thing to do with them is.
This risk is highly impactful for Product Owners who are essentially project managers, but it is not generally a problem for POs with different backgrounds. For instance, POs with a product management or analysis background tend to be excited about this transition rather than worried or bothered by it.
Prerequisites & Enablers
Recommended: Program: RMF 1 – Collaborating for Shared Understanding
RMF 1 is the primary enabler of this program. While not a strict prerequisite, it lays essential groundwork that makes BDD 1 more effective and easier to adopt.
Both RMF 1 and BDD 1 emphasize the importance of collaboration in requirement development—but they address different sides of it:
- RMF 1 establishes the mechanisms that make collaboration possible: it reserves team capacity for collaborative work, schedules it into development iterations, and makes those efforts visible and repeatable.
- BDD 1 provides the language and structure needed to encode the shared understanding that results from that collaboration—using clear, testable behavioral requirements.
Together, they form a powerful feedback loop: RMF 1 enables collaboration to happen; BDD 1 captures its outputs and reinforces the value of that collaboration.
We recommend completing RMF 1 before starting BDD 1. It’s not just a “pairs nicely with”—it’s the thing that prevents BDD 1 from becoming a disconnected documentation exercise or a well-intentioned effort that stalls due to lack of process support.
💡 Note: RMF 2 and RMF 3 are not enablers of BDD 1, but they do amplify its impact and maturity.
- RMF 2 introduces bespoke definitions of done, which can incorporate BDD scenarios as completion criteria—clarifying expectations and reducing rework.
- RMF 3 defines readiness at the work item level—ensuring that the item itself, along with all supporting team and organizational conditions, are in place before implementation begins. While not required, teams may choose to incorporate analysis techniques from BDD 2 into their Definition of Ready to strengthen the quality and completeness of behavioral specifications.
Related Programs:
- Program: PKB-Driven Development (PKBDD) 1
- Provides a shared, version-controlled Product Knowledgebase (PKB) where BDD scenarios and other requirements can live, evolve, and stay visible over time.
- Answers the critical question: “Where do we keep our BDD scenarios?” — with a practical, scalable solution accessible to Product and Engineering alike.
