Behaviour-driven stories

At a recent software architecture workshop, I was discussing the ideas behind BDD with a great group of people (more about that soon). One theme that kept coming up was the fact that I needed to write much more about BDD as an entire methodology, and to address the current perception that it is just a repackaging of test-driven development (which, to be fair, is where it started).

As I was describing the workings of BDD, I discovered that I had made the assumption that everyone knew what a Story was, in the agile sense of defining a requirement. It turns out that there’s a whole world outside of my little bubble that use all sorts of different processes for identifying and defining requirements, and in particular they don’t know what I mean by a Story, nor why they should care.

I was specifically asked what a story was from a behaviour-driven perspective, so I have written it up in an article called What’s in a Story?.

In the interests of releasing early and often, I will be editing and updating it in response to comments on this post. I’m particularly interested in people’s thoughts about how BDD stories compare to Use Cases. I’ve read a bit about use cases and used them a long time ago, but I haven’t been around them recently enough to really remember whether I liked them.