Story: <title>
As <role>
I want <feature>
So that <business reason>

In other words, a customer may write something along these lines:

Story: View music chart
As a music fan
I want to browse a list of popular songs
So that I can be motivated to buy something from the catalog

One of the immediate benefits of using this convention is that high-level requirements can be described and manipulated consistently and succinctly.
I’m particularly fond of the So that step: if well written, it often highlights the actual customer needs.
Once a need is identified, it becomes much easier for the development team to find further (and often cheaper) alternatives to the requested feature!

In the example above, “browse a list of popular songs” is the request, but being “motivated to buy something from the catalog” is the actual need. Can you imagine other features that would motivate customers to buy more? I certainly do.
The lesson here is that, almost invariably, customers request a longer antenna when they actually need a better reception. Trust me, this kind of deliberate creative thinking on finding alternatives can save you days, weeks, or even months of work.

Identifying the need is so important, in fact, that others proposed the following alternative convention, so that you can force users to put the reason of the requirement at the beginning:

In order to be motivated to buy something
As a music fan
I want to browse a list of popular songs

Are you still with me? Good. Let’s move on and discuss scenarios.
Differently from conventional, “fully dressed” use cases that I used years ago, a user story is usually written on a small card which acts as a placeholder for a subsequent conversation with the development team.
When the conversation takes place, the team would ask the customer questions such as: “what do you mean by that exactly?” To express and clarify the details of each story we write down a few scenarios:
Here, BDD can help us again with another template:

Scenario: <title>
Given <some initial context>
And <some more context>
…
When <some event occurs>
Then <ensure outcome>
And <some more outcome>
…

For example, customers, testers and/or developers could write and discuss the following:

Scenario: Browse chart
Given visitor is logged in
And visitor is on home page
When visitor clicks on chart page link
Then page should display title “Top charts”
And page should display list of top songs

These scenarios can be used as both documentation and as acceptance criteria.
If you are new to BDD, there is a little twist. Each single step in the scenario is sufficiently small to be “automated”.

Indeed, there are already several frameworks (some more mature than others) that have story runners able to relate the intention (expressed by customers) to some code (written by developers), often using a simple naming conventions (e.g. a Given step can run an equivalent Given method). The list is growing fast: JBehave, RBehave, NBehave, RSPec, Cucumber, and so on.
At InnerWorkings, we experimented for a long time with various frameworks (including our own) but we now use a Ruby-based framework called Cucumber (a brilliant rewrite of the RSpec story runner, now deprecated).
Great stuff, you will say, but I don’t want to use Ruby. Your loss, I would reply . We love .NET too, but we use Ruby as well.

Although I’m sure many plain-text story runners based on .NET will emerge soon (if they are not there already), this weekend I started my own pet projet. Since it uses the new language ‘M’ (MGrammar, specifically) I decided to call it MisBehave.
I haven’t bothered building a story runner yet, but you may find this picture quite interesting:

It shows Intellipad, one of the tools provided with the Oslo CTP.

On the left column, I have an instance of the language. On the central column, I have the grammar I wrote, and the third column, shows the projected tree structure. So far, I have plain text converted into a structure that will be further processed by a program. Hopefully you can see where this is going.

I haven’t tested the grammar extensively. I will clean it up, add support for scenario reuse (GivenScenario), add FIT-style tables, improve the error notifications, and refine the projections.

A few people said that writing languages is difficult. Well, it is difficult indeed if you write general purpose languages.
For simple domain-specific languages though, the task is much simpler. I wish I could say it is really trivial, but I won’t

For educational purposes, you can download my grammar here (useful if you have the Oslo SDK).
Any feedback is more than welcome.
Now I’ll better stop toying around and start preparing for my presentation at Øredev!

When Dan North started illustrating the concept and his findings, I almost immediately felt that he was on to something with incredible potential; so much in fact, that I definitely consider that session the highlight of the entire workshop.

On the surface, BDD can be described as a simple refinement of test-driven development (TDD).

After practicing TDD for a while, it is easy to realize that test-driven development is more about code design (specification) than testing (validation).
In fact, it is about expressing the behavioural intent of the systems we are developing.

As a consequence, BDD is a practice that, at its core, advocates modifying the nomenclature of our tests to better support this mindset.

There is a lot more to it of course, but since I still have to prepare my luggage and I risk to be late for my flight to Barcelona (yep, I’m going to Tech-Ed Developers!) I won’t go into any detail today.
I will write about it very soon, however, as I’ve been trying it for a while and I think it is only fair to share my experience.

In the meantime, I strongly suggest reading the excellent article that Dan published for Better Software magazine last March and that now is finally available online.