Write Better User Stories. Use BDD.
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 partners — 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 innovation partners at Revelry.
Originally published at revelry.co on June 9, 2017.
