Behavior Driven Analysis

Behavior Driven Analysis (BDA) starts with patterns for mapping epics to features. It elaborates the invest properties per feature in a normal form, then categorises acceptance criteria according to cross-cutting themes. These themes represent categories of acceptance criteria covering all testable interactions between the product and key user personas, architectural dependencies, non-functional attributes and business rules.

Traditional Business Analysis often yields poor product-market fit:

• It gets bogged down in details and cross-referencing as requirements documents grow, leading to analysis paralysis.
• The paralysis is cut short by time pressure whereupon the product squad is tasked to deliver a half-solution – a compromised product – with incomplete acceptance criteria.
• Sometimes, in scrumbut programs, delivery begins before analysis has covered sufficient ground to assure business value will be delivered. This leads to rework and sometimes business case failure.

Behavior Driven Analysis is a way to quickly but systematically discover missing features and contract the scope of product squad comparisons of feature sets while also preventing cycles of dependencies between features. It works breadth-first to generate a simple acceptance matrix and may be quickly revisited upon new learnings about the quality of product-market fit, or new solution constraints and resource constraints that might invalidate previous planning.

1. Each currently contemplated feature is listed as a statement of intent in story normal form. If these features also have any bullet point acceptance criteria each bullet should also be converted into a theme.
2. Key themes relating to personas, architectural elements, business rules and non-functional requirements for one or more features are listed on the other axis of the matrix.
3. The intersection of a feature and a theme is regarded as a checkbox; each checkbox can only contain a blank or a checkmark. A checkmark means there exist some acceptance criteria for this feature in this theme. A blank means there aren’t any criteria for this feature in this theme.
4. Each feature is evaluated against all themes.
5. As each feature is evaluated, also consider whether there are acceptance criteria in a theme that aren’t yet part of the matrix. If so, add a column for a new theme that represents the category of those criteria and evaluate all the features to determine whether they also have some acceptance criteria in it.
6. It’s fine to modify or refactor features as you go so long as all the roadmap’s checkboxes are updated accordingly.
7. Evaluate each theme to determine whether it is sufficiently covered by features to deliver the scoping epic.
8. If not, extend the matrix with extra features to assure the theme is sufficiently covered, with each new feature evaluated in all the other themes too.
9. If it appears that all features have the same pattern of checkboxes for two themes, consider whether those two themes may be refactored into one.
10. If a theme has checkboxes for all or almost all features, break out the technical features to encapsulate the commonalities.
11. If a theme has no checkboxes ticked, delete it. If it has only a very small number ticked, consider refactoring those checkboxes into a standalone feature.
12. This process continues until the team agrees that the matrix is complete or it has reached the last responsible moment.

But to use Behavior Driven Analysis properly it’s essential to keep breadth first in mind. The mapping process will become long and contentious if features and themes are too numerous or too detailed. Each feature may be expanded into an epic if this occurs and a new matrix constructed for it. BDA is pointless if your epics don’t fit the market. Therefore, before spending very much time on features, do a pass at Impact Mapping. Finally, in order to determine budgets per feature and the optimal order in which to deliver features, use Business Bingo.