BDD. It's not about the tools but... just in case.

The agile manifesto says "Individuals and interactions over processes and tools" and I completely agree, the processes and tools won't turn your project into a success story, the individuals and interactions will. But what if you're already satisfied with the individuals and interactions and you're starting to look for how you could make your life easier. And here comes the role of the tools - to bring as less overhead as possible and at the same time help you meet your goals easier. That's what I was looking for when I decided to give BDD a try.
First I had to decide which of the following two approaches I would use:

• Rely only on the naming conventions for my test methods and do not introduce any new tool(s)
• Rely strictly on some of the available BDD tool(s) and leave my test methods' names "underscoreless"

I chose the second approach as using only the naming conventions one can't describe the user stories and the scenarios with as many details as necessary. Also using some tools you can introduce other stakeholders (QAs, business analysts, etc.) to the project easier.
As we're already using heavily MSTest I decided that I'd better choose tools which could be integrated with it rather than switching to NUnit (although the NUnit constraint model looks quite tempting). That's why it didn't cost me much time to select StoryQ and NetSpec from all of the available tools. StoryQ provides the infrastructure for you to easily author user stories and scenarios (the acceptance criteria) and NetSpec provides some useful extension methods to help you switch to the BDD-should-lingo.
With StoryQ the effort for introducing other stakeholders to the project would be even smaller as it provides a convenient tool for converting stories and scenarios written in plain text into test methods, and the non-developers would definitely appreciate that.