Staring with event storming, you take the business rule and convert it to example mapping. Then when you switch the tool and you think in a different way, you can come up with more and different scenarios. Once you get the examples out, you can formalize them.
What makes a BDD scenario good?
There is one rule per scenario.
The what is described, not the how. Don’t use CSS in the description.
Obvious is omitted.
No intentions, there is no “want” in the sentences.
One of the advantages of having the scenarios first and using them to drive the code is that the business language naturally flows down to the code level.
It is important the scenarios reflect what is in the code while it is in the language of how business people talk about the functionality. If it is not the case, then you haven’t created a good model.
In many organization they are systematic issues that are preventing them from being able to collaborate effectively.
Sadly, I have been told at a company: “we are using BDD because we are using Cucumber”. This statement is so wrong on so many levels. Organization that is not ready for these ideas and they are adopting only a small fraction of the practice and getting a small fraction of the benefits.
Badly interpreted BDD can end up testing the whole system through the interface. Maintenance nightmare that can add work to whole teams whose job is to get the BDDs work again. It doesn’t give value to any team.
If you start with doing something with example mapping to understand the work that you are about to do, that can add tremendous value to the development team.