Folks in the Agile community have long suggested that user stories are placeholders for a conversation. That pronouncement may leave you with some questions, such as who should be included in those conversations, when do you have these conversations, what should you talk about, and how do you remember what you said?
Behavior Driven Development (BDD) provides a synthesis of techniques that helps to answer these questions. The core idea of BDD is your team should discuss the expected behavior of a product as you prepare to build a specific increment of it. It’s important to understand the specifics of those conversations.
Who should talk about user stories?
You generally want the people who have the most information about the intended outcome of a user story to be involved in a conversation about it as your team gets ready to deliver it. You also want to make sure that you have different perspectives involved in that conversation.
The Three Amigos pattern describes those three perspectives:
- A business perspective (usually the product owner) – someone who can speak to the desired outcome of the user story.
- A development perspective – someone who can speak to how the team could go about delivering that outcome
- A testing perspective – someone who is good at thinking up all of those “what if…” type scenarios.
When do you have these conversations?
Conversations among the three amigos about a user story general happen during an activity formerly known as backlog grooming, now more commonly known as backlog refinement. While some teams schedule backlog refinement as a specific meeting, it’s more effective when it’s treated as an ongoing activity.
If you’re a product owner, you should continuously look at the backlog and consider priority, items that are no longer needed, and the degree of readiness of items that are next up for delivery. When you identify an item that is due to start delivery shortly, that’s when you can ask your friends to dive into a deeper discussion about that item.
What should you talk about?
Once you have people with these three perspectives gathered together, you can dig into an in depth discussion about the user story (or user stories in question). At Agile2015 Matt Wynne introduced Example Mapping, a technique that helps to structure the conversation around a user story that focuses on drawing out all of the relevant acceptance criteria (Matt refers to them as rules), related scenarios and pertinent questions associated with that user story.
When you structure your conversations this way you can build a shared understanding among your team about what scenarios you do and do not need to account for when you deliver the user story. You’ll find that some acceptance criteria need to be further explained by scenarios, while others are pretty self explanatory. When you talk about those instances as a group you can clarify everyone’s understanding about what is necessary and avoid wasteful all or nothing rules such as all acceptance criteria have to be written in the form of examples.
Example mapping also gives your team an opportunity to identify what you don’t know yet about a user story and create a set of questions that you need to research further. When you do that before delivery work starts, the flow of the actual delivery activity goes much smoother.
How do you remember what you said?
Example mapping gives you a way to discuss scenarios relevant to a user story without delving into those scenarios right there. That doesn’t change the fact that you may eventually want to have more specifics about a particular scenario, and that’s where Gherkin, also known as Given When Then comes into play.
Gherkin provides a format to describe the behavior of a product when it starts at some precondition and some action occurs. Your team can use it to remember what you discussed about responses the system provides to certain activity, and these statements can also be turned into automated acceptance tests.
The Acceptance Criteria you discuss around a story and any models you might sketch as you have the discussions can also help your team remember what you talked about. Every user story will be different as to the number of acceptance criteria and models you need to keep about it in order to remember what you talked about so don’t feel compelled to create a bunch of documentation if you don’t need it to build and maintain a shared understanding.
What are your experiences talking about user stories?
Have you used Example Mapping? Do you have another technique that you’ve used to learn more about user stories? Leave your thoughts in the comments.
