It doesn’t take long for teams to learn just enough about behavior-driven development (BDD) to be excited. I used to sit for a couple hours with business analysis, developers, product owners, testers, and even managers, showing them the fundamentals of BDD. My goal was to help them hit the ground running by answering questions for them: What are we trying to do with BDD? What does a feature look like? What’s a scenario? What is Gherkin Language and how do I write my tests? Where’s the value in BDD for me, for my team, and for my organization?
We would work through a few BDD examples together, then they’d disappear to a meeting. The next time I checked up with them, perhaps the next day, they invariably had slammed out a good number of scenarios. Great! We would sit and talk for a while about how to clean things up a bit. They would then disappear and return with even more the next time.
As long as I stayed on top of my “would-be” behavior-drivers, this back-and-forth seemed productive and straightforward. If I touched based with them soon enough, it was easy to correct the various, common problems that would arise.
However, I eventually realized that I was leading my learners down a not-very-agile path.
Embracing a Just in Time Mentality
One of the aspects I learned to appreciate about agile is the just-in-time mentality it promotes. We defer as much as we can, until as late as possible. Waiting until the last responsible moment sometimes results in the joyful revelation that the effort is no longer needed, or that we avoided having to rework something already solved. The gift of time, earned by the simple acts of demonstrating patience and avoiding speculation.
Asking folks to go off and produce piles of given-when-then’s isn’t very “just in time.” Investing discussion time and angst to derive given-when-then narratives is a waste of time if a scenario gets discarded. Even if they do ultimately build to a scenario, the details are reasonably likely to change between now and then.
Negotiating the Behaviors
Part of our goal in producing given-when-then narratives (I’ll call these the “specs” moving forward) is to ensure we, the organization asking for capabilities and the team delivering them, are all on the same page. Try viewing deriving the specs as an agile form of contract negotiation: If the business agrees that the specs represent their interests, and if we deliver a system that meets all those specs (i.e. that passes all the tests), the business agrees to buy it.
When do the specs become a binding contract? The simple answer: When we agree to take on and deliver the behavior they describe. If we’re employing an iterative agile process like Scrum, that moment is at the outset of the iteration when we take on the work. Even then, testers and developers can continue to negotiate right up until the moment we deliver the goods. It’s software, so nothing needs to be finalized until it’s shipped… and even then, we can agree to change it. In agile, we negotiate our “contracts” continually.
Until the moment we’re considering taking on the story, we do not need to flesh out all narratives for its scenarios.
Do We Need a Narrative to Discuss Things?
Agile is an incremental, iterative process. The “iterative” part means that we continually refine things: we start at high levels, and then cycle down toward the low-level details needed to ship a product. With respect to behaviors, the business desires (or “requirements”), we start with a story. Never mind folks who think “story” is a synonym for “requirement.” Think instead of a story as the real-life thing: it’s a discussion that begins with the business telling us about what they’d like.
A story starts as a simple tale but gets more interesting and detailed as we talk. We flesh out our understanding of a story by asking questions: “What happens in this case?” Our questions are often answered with summary descriptions:
“We’re working on the library feature that allows people to self-scan and check out movies. The system prevents underage patrons from checking out adult movies. However, half of the kids are sneaking off with the movie. What should happen?”
“Oh, dear! I guess we need to worry about that. It should probably send a notification to the librarian’s machine at the desk.”
“OK. We’ve noted a scenario titled: movie checkout by underage patron sends notification to librarian.”
We collect the summary descriptions; these become our scenario titles. When we’re closer to building, we can do iterative refinement by providing specific given-when-then narratives for each scenario.
In the meantime, however, the scenario titles might be all we need. It takes but a smidgen of imagination to think about what the narrative might be for many scenarios, including the one above where a child checks out a restricted movie.
When we discuss the desired behavior, maybe just prior to the outset of an iteration, we want to get some sense of what this thing really is, and accordingly, how big it really is. Deriving solely the list of scenario titles can quickly help us to agree on the scope that we’re ready to tackle now.
Suppose for the checkout feature we have a handful of basic scenarios… then someone remembers to ask the question, “But what about the underage patrons?” Oh. We now we have a different picture in our mind. We quickly realize there are at least a handful more things we must consider: we must add ratings to the movies, we must ensure we capture the patron’s birthdate, and we must ensure that our new notification feature doesn’t impact adult patrons or underage patrons checking out non-adult materials.
Do we need to detail these new scenarios? Not yet! We realize that the story no longer represents something small. The product owner decides that we can worry about those needs in a later iteration. She has something more important for us instead. Effort expended on detailing the specs for the underage patrons: none.
Occasionally we do need a detailed narrative in order to gain a better understanding (“What do you really mean? Show me an example.”) or make planning decisions (“That could work one of two ways… let’s talk through the two variant narratives”). Spending the time to provide details for an occasional scenario is fine. What we want to avoid is always diving deep before we’ve explored the breadth of a story. And from a timing perspective, the deep-dive into narratives can occur immediately following the use of the scenario names to determine scope.
Next time you start a conversation about a feature, first pin down the list of scenario names and use those as a basis for the discussion.
