This article is part one of a series that demonstrates the benefits of BDD. We review problems a typical user story runs into from refinement through delivery and how BDD mitigates or solves these problems.
Our goal is to help you understand the case for BDD. Whether you’re a change agent, an influencer, or a leader in your organization, this series will help you make the business case for BDD.
If you’re not familiar with BDD, it might help to read What is Behavior Driven Development? first. Hint, there’s a lot more to BDD than test automation.
Let’s start following our user story from the beginning in Backlog Refinement.
Our User Story is in Backlog Refinement…
We are in the weekly backlog refinement meeting again. Everyone is excited to hear about the cool new work coming up.
As usual, our PO describes the business goal and how we plan to meet it. Our designer shares some wireframes that clarify quite a few things.
We talk through the user stories and several people on the team ask questions. We’re feeling pretty good about the work to be done, this is going to be interesting and fun.
Story sizing forces a bit more conversation, so we’re really feeling on the same page by the end of the session. The PO makes some minor edits to the user story and the designer agrees to tweak the design based on our conversation.
Right now, it’s all good feelings, but as time will tell, we’re not as aligned as we think.
Problem: A Team Member Missed the Refinement Session
Next week roles around and it’s time to do backlog refinement again. Joining us this week is a colleague who wasn’t able to attend the previous session.
We need to catch our team mate up on the previous week’s conversation but how?
The only artifacts from the conversation are the user story and the wireframes. This leaves quite a bit of missing context so we end up rehashing last week’s conversation. This takes up a good portion of the meeting.
Solution: BDD + Example Mapping
With BDD, we use a technique called “Example Mapping” to enhance our backlog refinement. This technique creates a visual representation of the story’s business rules, along with concrete examples that help to illustrate each rule.
Example Mapping is fast, engaging, and provides structure to the conversation. It also pulls the entire team into the conversation. Our refinement sessions are more fun and uncover edge cases we typically missed in the past.
It also produces a visual artifact, an Example Map that helps anyone understand business rules quickly. If we had one, our developer that missed refinement would have come up to speed more easily.
We also use example maps later in our process to keep development and QA in sync. More on that later.
Problem: No One Agrees about How the System Works
Later in the refinement session, as we talk through another user story, people start asking very detailed questions about related functionality in the system. Pretty soon it’s obvious that team members have different recollections of the existing functionality.
A new team member mentions our documentation, but everyone else groans because it’s somewhere between 12 and 18 months out of date. We all know of many changes since then.
So what can we do?
Before we can understand the scope of this story, someone has to go read the code to figure things out. Of course, the person that knows that part of the system best is knee deep in work on the current sprint. This is new work that will impact our current sprint delivery or slow us down next sprint if we don't do it now.
Solution: BDD Provides Living Documentation
With BDD, we build a library of Living Documentation. These are structured documents built from our Example Maps. We write these documents in the form of Gherkin.
Our Gherkin documents are validated by our automated tests. Our automated tests tell us if we accidentally break an existing business rule and validate that our documentation is correct. That's why we call it Living Documentation.
Now we can reference our documentation with confidence. We also make our Living Documentation available to our stakeholders so we don’t get questions about how the system works any more. We never thought this was possible before BDD.
Summary
Even before our user story gets out of refinement, we’ve seen benefit from BDD. Here are the highlights:
- Example Mapping makes our refinement conversations more fun and engaging. It also helps us learn earlier in the process, uncover hard to find edge cases, and produce an artifact that illustrates our understanding.
- Gherkin structures our Example Maps into scenarios that document the system behavior in business terms. Our automated tests are connected to the Gherkin to validate the documented scenarios.
- Living Documentation is the result of integrating documentation with automated tests. We know the documentation matches the system because the automated tests are passing.
