BDD is a collaborative game of exploring the desired behavior of a software system.
People with different roles—usually product owner, developer, and tester—use examples to emerge this behavior rather than one individual trying to specify the behavior up front in isolation.
Example mapping is a good technique for structuring a discussion around examples.
Use real, concrete examples, not unrealistic dummy data.
Use a common or happy path example to get to work on a real, concrete thing right away. Come back later to handle variations rather than trying to fully specify a story up front.
Not everyone will be on board with trying a new way of working. Treat resistance as a resource, a source of information to engage rather than something to fight or avoid.
Games like BDD have a natural structure—opening, exploring, and closing. Don’t rush through the stages.