Today we tried to introduce BDD in our software development process by having a specification workshop.

For this workshop we had 2 developers, 1 tester and 1 business analyst. The workshop lasted 1h30 and by the end of it we managed to figure out some BDD scenarios for our new feature. We tried to focus on finding the scenarios that we could miss, and the difficult ones.

At the end of the workshop some people were actually unhappy with the workshop.

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. The business analyst didn't feel confident with our scenario coverage (Had a feeling that we could have missed out other important stuff) 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.

This experimental workshop lasted 1h30, and by the end of it, we didn't feel confident enought about what we did...sure we could have spent more time on it but honestly most people get exhausted after 1h30 of brainstorming to fetch out business rules from the BA brain.

So my question is how that kind of workshop can actually work. In the theory, given you have a new feature to develop, you put the tree 'amigos' (dev/tester/ba) in the same room so that they can collaborate together on writing the differents requirements for the new feature using examples. I can see all the benefits from that. Specially in term of knowledge sharing and common product/end goal/done vision.

Our conclusion from this experiment was that it is actually more cost effective to first have a BA to work on his own on the examples and only then to have the scenarios to be reviewed/reworked by the 3 'amigos'. By having the BA to work on his own, we actually feel more confident that we are less going to miss out stuff + we still get to review the scenarios afterward to double check. We don't think than simple one time brainstorming/deliberate discovery session is actually enought to seriously cover all the requirement for a new feature. The business analyst is actually the best person for that kind of stuff. The best thing we can do is to review what she wrote and see if then we have a common understanding (which could then lead to rewrite some of her scenarios or add new ones she could have missed).

So how can you get that to work effectively in practice ?


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.

  • Thanks for this detailed answer, I reckon that we might have spent too much time writing some scenarios with all the Given When Then, whilst just noting a brief description would have been enough and could have saved some time. If I understand correctly your answer, the goal of these workshops is to just to talk about the "difficult" stuff or the stuff that could lead to misunderstanding and it is not about getting high requirement coverage. The simple stuff can be written by BA on her own. – foobarcode Nov 19 '12 at 19:13
  • That's a good way of putting it, yes :) Also, having the conversations is more important than writing them down, which is more important than automating them. – Lunivore Nov 19 '12 at 21:48
  • I've found "I'm not sure" to be quite common. Often somebody knows the answer - but not the person the devs are talking to. Tracking down the right person can take a while... – DNA Jul 4 '13 at 21:00
  • 1
    @DNA I've covered complexity estimation in more detail in this post: lizkeogh.com/2013/07/21/estimating-complexity - the ease of tracking down expertise is indeed part of the metric. – Lunivore Nov 30 '13 at 18:10

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.


  • 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 answer here already, so I've going to focus on one small aspect; the role of each of the Three Amigos should able to deliver to the session.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.