Recently while working with an organization going through a large Agile adoption I had the opportunity to work with a team that was open to adopting BDD acceptance criteria story development. One of the key differences for this team was that this was the first time that they had experienced a collaborative story development effort. Prior to this most teams in the organization looked to the Product Owner to write all of the stories, which led to stories that were not contextually rich, had little to no acceptance criteria and were difficult to demo at the end of the sprint.
As I discussed the success of the teams use of BDD I was surprised to hear feedback that indicated the organization wasn't ready for the heavy lift of using BDD and that I hadn't moved the team into BDD because their final work wasn't automated.
If that is your position then I think you are missing the point of BDD. Yes BDD is great in that when you right acceptance criteria in the Given/When/Then format and build your example tables correctly you can obtain automation fairly easily with tools such as Cucumber, Fitnesse and a whole host of tools that have been developed to support this very successful way to build out what I call 'contextually rich' user stories.
However even if you don't automate your BDD acceptance criteria, the value you get from understanding the behavior of the features you are going to build is invaluable.
BDD came about because Dan North realized that TDD and really great code meant nothing if it didn't deliver the value or functionality that the stakeholder needed. This concept was clearly illustrated for me at one organization I worked for when the Development Manager was lamenting about a Product his team was enhancing was pulled from the market because they didn't deliver on time in order for the organization to stay competitive in the market. He said 'If only they could see all of the cool code that we've written'....To which I said 'Business doesn't care about code they care about delivery" no matter how great your product is from a code perspective it matters not at all if you don't deliver it when your customer needs it.
For those of you who are exploring the use of BDD with your Scrum teams understand that there are essentially two separate efforts that effective teams are working on:
1. Team collaboration - Successful teams using BDD understand that they all need to be involved when building out user story context with Given/When/Then. In fact I would argue that this is the most important element that drives a clear understanding of what we are building and guidance to when a user story is done.
2. Automation - One of key components of successful Agile teams is the development and maintenance of an effective automation suite. Utilizing BDD provides an effective way for teams to obtain high levels of automation and do so within the Sprint that they are working in. A common mistake of newer Agile teams is to develop in one sprint and test in the next and sometimes automate in the third. Using BDD automation tools such as Cucumber with well written acceptance criteria (I'll provide examples of well written BDD in my next blog post)
A third benefit of BDD is that a Scrum Team builds a clear understanding of the scope of the story. Since everyone participates in the development of the acceptance criteria, if a scenario is missed, it's a shared miss - No finger pointing, just manage the new scope with a new story and prioritize it in the backlog.
I've helped a number of organizations implement BDD effectively, one of which did not have any automation at all. The use of BDD acceptance criteria writing almost immediately improved the understanding of the features being developed and helped my QA team write significantly more test cases than they had been doing. This effort led to a measurable improvement in Quality even before we added the automation suite later.
Having come from a waterfall world many years ago I can tell you that when you 'get' BDD, it changes the way that you look at requirements and provides you with a mental framework that you can quickly use to model what is going to be built.
After a few months of using this format at Disney the Product Owners were uniform in their agreement that there simply was no other way that they would want to work with their teams.
Automation IS our goal, but it is not what defines BDD.