As you might tell from some of my blog topics I'm a huge believer in BDD, not just as a means to automation but more importantly as a process that helps us define requirements more accurately. When we move into an Agile delivery model, many individuals struggle to understand how they are supposed to document everything that they used to put in their Product Requirements documents (or a whole host of other acronyms). These documents formed the basis of our engagement with the business and with the teams that would ultimately deliver what the business thought they were asking for in the PRD.
There is an interesting game that has many flavors such as Social Telephone game, that for me, makes clear the issue with large documents that multiple groups need to review. Each of us is individually focused on the things that we think are important and we often have different interpretations of the written word. And as such as we work to deliver in our silos we move towards an uncommon understanding of what is being built. I would argue that many 'defects' that are found are actually poorly interpreted requirements.
For those of you in highly regulated industries you know what I'm talking about. The endless hours spent reading a single paragraph trying to derive the real intent and meaning behind the written word is exhausting and fraught with peril because if we get it wrong there are penalties and mad scrambles to implement a hack to make it work the 'right' way.
Software development is made hard because of these communication differences, be they cultural, language or other, they exist and they make it difficult to come to a collective understanding of what is being asked for.
User stories help break down this barrier as they define small pieces of a larger whole and place a value statement so that we understand WHY what we are being asked to build is important. Many teams writing user stories leave off that important 'so that' statement. Leaving off 'so that' leads to so what?
Behavior Driven Development, for me, changed the way that I looked at defining requirements because it removed the business language of things such as the business requires this, or the feature shall do that. The statements sound powerful yet deliver little in real context for the teams to work from.
Breaking down user stories with BDD still leaves the team to work with a non-technical domain language and then provides a clear method of defining the behavior (positive and negative) for the teams to work from.
The power of context with the respective speed and quality it delivers can't be denied. However don't be fooled that this is easy, it isn't. Agile is extremely disciplined, something many miss on their way to the Agile party. Done right it can take your delivery processes to new heights, done wrong it becomes just another new fangled process that doesn't work.
Below is a BDD tutorial that can get you started on your way to learning how to build contextually rich user stories. Good luck and have fun!