BDD 1 teaches teams how to identify a specific scenario, write a specification for it, and then use it to drive implementation. However, we rarely only have a single scenario to deal with.
In general, an event that occurs under one set of conditions is likely to occur under many other conditions as well. It is important to identify the full list of conditions that need to be addressed and, also, which sets of conditions you’re going to deal with, later, if at all.
One challenge is to have all of these identified. Teams struggle with this especially since most business stakeholders do not see the full complexity of the potential requirements, especially since they tend to focus only on their own areas. As a result, they do not provide the rich requirements needed for teams to address all the different potential concerns.
For instance, the same scenario might need the perspective of many different stakeholders, e.g., UX, Security, Legal, Finance, and Performance. They will each likely think of scenarios that may arise and need to be addressed that other stakeholders will not think of.
Furthermore, these stakeholders will likely have different views of what the system should do under the same set of circumstances. Sometimes these are conflicting, and sometimes they’re complimentary. Therefore, another challenge lies in identifying this, resolving conflicts, and compiling the complete requirement for the scenario that addresses all the different aspects.
This course teaches the team and product owner the skills required to surface these scenarios and concerns so they can be addressed with the right stakeholders or be explicitly deprioritized. It also teaches them how to reconcile the different perspectives on the same scenario.
The result is more complete and coherent definitions of requirements before coding starts.
Additionally, failing to identify such “other” scenarios is usually the underlying reason for both missed scope and scope creep. This course gives teams the techniques to solve the underlying scoping problem. So, a beneficial side effect of this course is that it reduces 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 1-day course and 4 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 next level of BDD skills, expanding the existing BDD analysis & handoff loop to include several advanced analysis techniques, ensuring a much richer set of requirements when 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 plenty of examples and exercises to help cement the ideas and practices in the learner’s mind.
Coaching
Afterward, a recommended 4-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 two days of coaching are in each Sprint.
In the sessions, the coach will lead the team through the process of applying advanced BDD analysis to each of several upcoming PBIs. Initially, he will play the role of inquisitor. He will drive the analysis by asking questions. Then he will gradually transfer control of the analyses to members of the team, offering guidance when they need it.
It may be necessary for the coach go through several cycles of “leading from the front” to “leading from the back” of the analysis effort. For instance, the team may need to alternate between seeing it done and practicing it.
Benefits
BDD 1, gave a team the ability to create a clear, concise, shared understanding between Product and Engineering. However, there was no rigorous framework for exploring or analyzing scope. Finding related scenarios or key stakeholders was left to chance. There also was no structured approach to making sure that each specification is good. It is likely that superfluous details were left in some scenarios. All in all, while BDD 1 gives you specifications that are good, they still tend to leave plenty of room for interpretation.
This level of Behavior-Driven Development teaches a rigorous, repeatable framework for hardening specifications by eliminating potential misunderstandings and noncritical aspects. The same framework also drives exploration of specifications to uncover hidden scope. The capture and use of critical business knowledge, such as a list of stakeholders to review, guarantees that vital perspectives won’t be missed.
This level of BDD introduces a “taste of analysis”. It is a small set of analysis techniques that are easy to adopt and require a low level of effort but have a very high impact in identifying missing scope and misunderstandings. As a result, it helps the team accomplish more complete analysis in less time. On top of all that, it helps a team experience how valuable and helpful analysis can be, generating 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 will significantly impact capacity during training, immediately after, and in the next Sprint. The team will not be able to deliver anything during the 1-day course and is likely to deliver at 50% capacity during the four days of coaching thereafter. Therefore, when planning costs, you should consider a 2-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 3-day capacity loss.
Time to Proficiency
You can expect your team(s) to stay in the “practicing” phase of adoption for four to six weeks.
Risks
You should plan for the fact that the teams will be discovering a great deal more potential scope much earlier in the process. The Product Owner (or equivalent) will initially need time to determine what is in scope and what is out of scope, pulling in stakeholders as needed.
Another risk is that of perception: As scope gets clarified, given that more scope than usual might be identified, it might create the illusion that this makes things take longer. However, that’s not what is happening at all. All that is happening is that things which were previously left implicit until they became a problem are now being explicitly addressed early in the maturation of a PBI. Over time, this glut of “extra” work will even out, and it will ultimately lead to less work as a result of being able to explicitly descope low-priority scenarios.
You should plan for some delays and for the team to spend more of its time on analysis as it works through this initial onslaught of previously hidden scope.
Prerequisites
Enablers
none
