BDD 1

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:

1. That team will have less rework, which usually comes from people building the wrong thing as a result of a misunderstanding or miscommunication.
2. 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:

1. Impact on capacity
2. Time to proficiency
3. 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

none

Enablers

• Program: Requirements Lifecycle Transformation
  • Provides the mechanisms (DoR, DoD) to ensure BDD scenario writing becomes part of the team’s standard software development process.
  • Provides a place (PKB) to store and evolve the BDD scenarios as business knowledge and product requirements.
  • Provides the mechanisms (Analysis Items, Analysis Meetings) for reserving and accounting time for the team to collaborate on creating and maturing BDD scenarios.
  • Two of the biggest questions that come up in every BDD transformation are “where do we keep this?” and “when do we do this?” The Requirements Maturation System (RMS) provides satisfactory answers to these questions.
  • Without the RMS, the team is likely to struggle (at best) with where to keep the scenarios they have generated and with how to schedule time to do BDD analysis. There is a strong possibility that they will come up with a solution that is not fully effective. There is even a significant chance that they will abandon these efforts altogether.