Why Behavior Driven Development (BDD) Makes User Stories 100% Better

You’re not alone if you’ve come to the conclusion that your meticulous spec docs just aren’t cutting it when it comes to getting software built the way you intended. There is hope, though. I want to tell you how we tear down confusion and build up clarity by using a process called Behavior Driven Development (BDD).

You may have spent weeks — months, even — outlining your software ideas into meticulous speculation documents complete with tables of contents, diagrams, dependency lists, and more; all in an effort to describe exactly what you want built. Why does it always seem that what you get is nothing close to what you wanted? It’s the trap of spec docs and acceptance criteria.

Even if you’ve moved away from this top-down, waterfall-esque model of software development in favor of an agile framework, you might still struggle with writing user stories that provide the right clarity. Your team is getting overly caught up on literalness and acceptance criteria to the detriment of delivering creative, valuable solutions. And the solution for that is Behavior Driven Development (BDD).

You Down with BDD?

At Revelry, we use BDD for all members of the team – and yes, that team includes our clients — so that everyone is clear about the intended user experience in the final product. Revelry’s flavor of BDD is a process for describing software features that is biased toward user’s actions and the results of those actions. We even take things a step further and help readers of the BDD story to understand the business value – or at least a portion of the background — explaining why the new feature is being built.

Revelry’s Behavior-Driven Development Process

Our BDD stories typically include:

• A headline written in an abbreviated syntax to quickly describe who is taking what kind of action for what benefit: [User Role] – [Feature Set] – [Specific Action/Result].
  • We previously wrote user stories in a more traditional format: “As a (user role), I want to (use some feature) so that (I gain some benefit). We have since learned we can be more concise while adding even more clarity to our headlines, making our project boards easier to comprehend at-a-glance.
• A background section written in narrative style explaining the reason and/or business case for the feature
• And at least one scenario in a Given / When / Then format:
  • Scenario: (description)
  • Given (a particular context or requirement)
  • When (an action takes place)
  • Then (there is a result)
  • (And sometimes we need several loops of “Whens” and “Thens” to complete the story)

What This Means for Our Partners

When you reach out to Revelry to help you build a photo sharing app (hang on, please don’t actually build a photo sharing app; that is a horrible idea), you’ll want to explain a major function that your app requires. So, imagine you’re going to describe the interaction of someone selecting a photo from their phone’s gallery to share.

Start with the Headline

• Parent –  Photo Sharing – Select and Share a Photo

Go into the Background

• We know that our users love sharing photos of their day-to-day lives with friends. We want to enable our users to do this because it improves their experience of photo taking and it drives ongoing engagement in our application

Provide at least one Scenario

• Scenario: Select and share a photo
• Given I am in my photo gallery
• When I select a photo
• Then I can share the photo to my friends and family
  (h/t to Temo Diaz in the comments for suggestions to make this story even better!)

From there, the next story may be split off to describe what happens when the user selects the option to send (how they choose the people to send the photo to, for example).

And That’s It!

We may supplement this feature story with a sketch or a mockup, but at its essence the story is clear. Our customers understand and approve what we are building because the behavior and the outcomes are clear. Our engineers know what to build, and they’ve been given enough flexibility to figure out the best way to build it. Our QA team is clear about what to test.

And our customers, again at the end of the process, can complete the task of final acceptance without having to question what this feature story requires. No long, cascading dependency chart. No technical language required.

That’s the business value we deliver to our clients at Revelry.