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.


  1. Brilliant article! This BDD stuff is really starting to grow on me. While I haven’t had the chance to use it in a structured way in a project yet, I’m beginning to realize that it helps me in my thought process when thinking about business problems and communicating with the business people. Perhaps I’m doing “stealth BDD” :-P


  2. Dan,

    I think you are spot on in the article, the main problem I had with Use Cases was not so much what they were, but the way they were generally used. ie some sort of analyst wrote up a whole pile of them and then pushed off long before the developers arrived…

    however, to me, another difference is that ( the way I do it) stories are smaller. In the example in your paper, I would have probably made each scenario in your ATM story a seperate Story….

  3. What I have a problem with a bit is the translation phase from story to design. The thing is: take your example of the ATM scenario’s (how a good story should look like). It’s easy to follow, but the problem is that the different scenario’s all describe different characteristics which influence the design, however you run the risk of losing the overview of which characteristic elements are important (and thus drive your design) and which aren’t that important, or even which characteristics there are.

    To me it somewhat appears to be like (bad metaphore up ahead ;)) a long list of “it should this” and “It shouldn’t do that”. You then could end up with a single class and a couple of methods with all the characteristics implemented, though that design isn’t that great.

    So to me, the valuable aspect of having good stories (so you know you have analysed the domain properly) is great but should be placed in context a little more, like where to go from here? How to translate these stories in proper design? Which steps to follow? :)

    1. Hi Frans.

      This is intended to be the first in a series of articles describing exactly that: how the stories get translated into well-factored, working software, the interactions between the various participants, and how the process remains focused on delivering just what is required by the scenarios and nothing more. At least that’s the idea.

  4. To begin with, I wasn’t sure if users would take to the style of the story in Given, when, Then format. I thought testers would love it. But having introduced the business to it I encountered no problems – the scenarios turn out rather neat, and easy to follow. Everyone likes them a lot – occasionally I find some people write a scenario like they are writing a Test Case (with varying data instead of varying logic). But overall my experience has been very positive! :)

    1. Varying data is an interesting one. It implies there isn’t much incremental behaviour, just a set of inputs that need to match a set of outputs. I’m planning to come back to this in a later article.

  5. Eric Krause · ·

    I’ve been using your “What’s in a story” article as a guideline for doing my own user stories. I have also been spreading it around the office for people to read. My coworker pointed out that Scenario 2 gives the user $10.

    1. Good catch Eric!

      Luckily the story was written in plain English so it was easy to see where the error was. I’ll leave it in there though – I’m sure there’s potential for a follow-up article about debugging scenarios.

  6. Michael Hanks · ·

    Great article. I can see similarities between the scenarios (Given, When, Then) and the operation contracts that Craig Larman wrote about in his ‘Applying UML and Patterns’ book – the Givens equate to pre-conditions and the Thens are the post-conditions of the event.

%d bloggers like this: