Why Behavior Driven Development (BDD) Makes User Stories Even Better

You’re not alone if you’ve come to the conclusion that your meticulous spec docs just are not cutting it in 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).

But don’t just take our word for it.

At Revelry, we do custom software, design, and training.
Get in touch and let us know what we can build with you.

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 (BDD) Process

Our BDD stories typically include:

  • A headline to describe who is taking what kind of action for what benefit: As a (user role), I want to (use some feature) so that (I gain some benefit)
  • 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 You

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.

  • As a user parent, I want to share photos of my adorable children so that their grandparents get off my back so that others can get a glimpse of my life.

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 a photo and share
  • Given I am in my photo gallery
  • When I long-press a photo thumbnail
  • Then it is selected
  • When I have selected at least one photo
  • Then I see an option to send

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.

Want to know even more about our process?

Go for a deep dive into the Lean Agile Process at Revelry.
Get in touch and let us know what we can build with you.