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.

The length of the meeting is not your problem. It’s OK for those meetings to go on a long time. BUT everyone should come out of it feeling confident. That they didn’t is your problem.

I would suggest a short meeting to discuss a requirement. Schedule a second meeting a few days later, so everyone knows they must be prepared by then.

Then the BA and tester should each come up with their scenarios, because they both look at software in very different ways. Get them to write them on cards and stick them all on a board somewhere, at least a day before the second meeting, let everyone look through in their own time and think it over. Throw away any duplicates, stick up any scenarios that weren’t considered.

Don’t throw away anything you disagree with, but mark it as contentious. If a very brief conversation with the person who wrote it will help, do that, but mostly save it.

THEN have your planning/design meeting. Have a solid agenda for that meeting (start with the pile of cards, put the contentious ones at the top) and don’t allow it to wander off-track. Make sure you come out of that meeting with all points of contention resolved.

Always make sure everybody in a meeting is prepared for the subject of that meeting!

Do not ever use a meeting to “brainstorm” anything together. It wastes everybody’s time.

General recipe for effective meetings:

• have someone prepare the items to be discussed
• require all participants to have studied (not just read) them those items
• gather comments beforehand and require all participant to have studied (not just read) them
• hold the meeting to take decisions

About the Complaints…

Let’s start with these:

One developer felt he wasted his time as he was used to be given out the scenarios directly by the business analyst and review them with her.

Which is what he was doing in the workshop. So that seems like a moody and bad excuse to me. I’d suspect this developer just doesn’t like either (or both) the scrutiny of the workshop and its scheduling constraints.

The business analyst didn’t feel confident with our scenario coverage (Had a feeling that we could have missed out other important stuff)

How is this different than when she does it on her side and has it reviewed by a developer, apart from the fact that more people looked at it? I’d suspect this is just the outcome of workshop being maybe a bit chaotic. You’ll get confidence that you have enough tests by implementing them and integrating them. You can never be sure you found all bugs, and when it comes to coverage, the best way would be to diagram them in your user stories.

but more importantly felt that this workshop was also a waste of time as she could have figured out all these scenarios by herself and in a shorter period of time.

Yes, and entirely on her own, in her walled garden, and without sharing knowledge. Whereas by doing this future workshops might be more productive as all participants have gained a little knowledge of how to approach these things.

Maybe the meeting was slow this time, it doesn’t mean it will always be. And as an external personal, I’d have, given some training to get this right, more confidence that the coverage was better in a workshop with 3 participants with different mindsets that with a single dictator.

Also, if there already was a need for a developer to review these scenarios with her, I’m pretty sure the back-and-forth is much faster and efficient in the workshop than using the “I do my stuff alone and give stuff to you, you review it alone and get back to me and let’s do this again” approach.

Suggestions

• Be positive and stress that if the process is right, you’ll get better at it.

• Try to streamline the workshop and keep it on track.

• Maybe give some room for “lone-wolf” analysis, by starting the workshop with everybody designing a few scenarios on their own (even better, before the workshop), then triage and merge them.

And if you don’t think doing that brainstorming thing is needed, fine: have the BA work alone, but then do the review as a workshop, at least. The more eyeballs the better, to quote Eric S. Raymond’s Linus’ Law:

Given enough eyeballs, all bugs are shallow.

You have some pretty good answers here already, so I’ve going to focus on one small aspect that has so far been overlooked. The role of each of the Three Amigos should able to deliver to the session. They each offer value in different ways, they each understand a different set of constraints.

In general the BA should be able to bring the main happy path to the session, they should be able to also provide the main failure scenarios from a business perspective. The Test expertise should be able to identify edge cases and additional scenario necessary to prove the system works in all circumstances. The job of the developer is not really to add scenarios, though they often will for technical failures, their job it too ensure the have a full understanding of the requirements so they convey implications and implement the requirement with the minimum of extra communication.