If you can derive the scenarios from the description, you're done.
An anti-pattern that I often see in BDD is people feeling the need to talk through, and write down, every scenario in detail.
Some scenarios are so well understood that it's enough to derive them from a brief description. For instance, if I say, "I'd like the login feature this week," you know what that should look like. You know that there are scenarios for the right password, the wrong password, the wrong username. We don't really need to talk through those or capture them in detail.
Similarly, I might say, "Here's the form for user registration. We need to be able to create new users, let them edit their details, and delete themselves, except that deletion shouldn't actually delete, it should just mark them as deleted so they can recover their accounts if they want to."
And you can ask, "Is account recovery part of this feature?"
"They can be two features if you want."
"Okay, so we have scenarios for create, read, update, delete; that should be easy enough. Let's talk about account recovery; that sounds more interesting."
In general, if the description of behavior is enough for the dev team to derive the scenarios, you don't need to talk through them. You can do so if there's any doubt, but you may just want to capture which scenarios you need to remember, if you capture any at all.
If you've never done it before or you're uncertain, talk through the scenarios.
Focus on the areas which are unusual, particularly if there are features you've never done before. These are fantastic places to have conversations and write down any surprising examples which come up. I usually have two questions I ask, based on the BDD template:
Given a context
When an event happens
Then an outcome should occur.
- Is there any other context which, for the same event, produces a different outcome?
- Is there any other outcome which is also important?
If everyone at the table is looking bored, the feature you're talking through is probably well understood. It's often enough to say, "It should work like X, but with Y instead." This is what Dan North calls the Ginger Cake pattern; it's like the recipe for chocolate cake, but with ginger instead of chocolate.
Even if the business stakeholder is able to derive the scenarios himself, it's really important for the dev team to be able to talk to him, pick up and internalise his language. That language then gets carried into the code, enabling them to have better conversations in the future, and helping newcomers to the project understand what's going on. If the devs don't get to speak the language, they won't use it.
If the business stakeholder or analyst really doesn't want to spend the time capturing things in the session, I'd rather the developers wrote the scenarios down in collaboration with the testers, then asked him to review it. This is more likely to uncover misunderstandings than the other way round.
Sometimes BDD doesn't work.
Another possibility is that you find a scenario the business stakeholder is uncertain about. "Oh, I hadn't thought of that! I'm not sure." Rather than trying to nail the business down and punish the business with certainty, it may be worth abandoning BDD at this point and trying something simple out to get some feedback and give the business something over which they can iterate. Keep it easy to change, and write the scenarios once there's a better understanding of what's going on.
BDD done well can really help to uncover places of uncertainty. Since every project worth doing has some aspect of it that's new and has never been done before, there is some uncertainty in there, somewhere. If you focus on using the scenarios to help deliberately discover ignorance, you'll learn faster, and learning is usually a large part of the time spent on a project.
Additionally I've found that the more dev teams collaborate in this way, the more the business are prepared to trust them with uncertainty, and the more innovation starts to occur. Innovative companies, by their very nature, have plenty of uncertainty in their projects.
I wrote a blog post a while back on Cynefin, which I find really helps me understand where the conversations will be most effective. If you read it and understand the four domains, here are the rules I use:
Simple and complicated stuff (known) is often well-understood and you don't need to talk through the scenarios in detail.
Highly complex stuff (unknown) is not understood at all. You may discover this by talking through the scenarios. The lack of certainty means that BDD won't work here, so iterate over something easy to change and get fast feedback instead. Any practice which retains your options, like A-B testing, is also great in this space.
BDD works brilliantly in the space in between (knowable) as a mechanism for passing on knowledge, and to uncover the other two spaces. It's not a hammer, and not everything is a nail. In fact, if you can focus the time spent having conversations on anything, it's not about the examples you can find; it's about finding the examples you can't.
Best Answer
BDD is actually TDD with fixed terminology (see here).
BDD wiki provides a clear explanation. If done right, it can work quite well. At least it worked very well in my team when we switched from almost cowboy coding. The code coverage increased, and with it, the number of bugs reduced, and quality increased.
What is also good about it is that you automatically get YAGNI, KISS and if done right SOLID.
As other development methods, BDD is not a silver bullet (such thing still doesn't exists in the software development). If after some time you do not see improvements in the code quality, then it's better not to use it. Under code quality, I mean : less bugs, easier to implement change requests, etc.