Behaviour Driven Development with strong scenarios is the agile answer to use cases and documentation that’s out of date as soon as it’s written.
BDD – Working with Scenarios
Behaviour Driven Development (BDD) or Specification by Example is the process of writing acceptance criteria as tests, using the defined format of Scenarios.
Some teams take this further using a tool such as Cucumber to automate the tests, but the primary benefit of writing scenarios is to use specific examples when discussing the functionality and constraints of a feature before implementing it. This allows us to bring the specification into the tests we write, eliminating the ‘defect-injection-process’ of writing specs first then deducing tests and code from them separately. It also brings us closer to creating truly living documentation.
Recently our team’s focus has been on creating better acceptance criteria for stories. One of the problems faced is that it looks deceptively easy to write a scenario in the format; “Given (a context) When (an event occurs) Then (we should have a result) …but of course, as it turns out, there’s a lot more to it.
Understanding the Concepts
Armed with insights from Kevin Trethewey and Mark Pearl’s Specification By Example session at SUGSA’s CodeLab, and going back to source’ with Dan North and Liz Keogh’s blogs on the topic, we gathered the following key points about User Stories and Acceptance Criteria:
Kevin Trethewey & Mark Pearl Specification By Example:
- Specifications should be stated declaratively, not imperatively.
- Pattern of a Scenario: Get a system into a state > Poke it >Examine the new state
- Stateless: Each scenario must make sense and be able to be executed independently of any other scenario.
And:
- Having conversations -> is more important than capturing conversations -> is more important than automating conversations.
- It’s more important to keep the conversation fluid and allow ideas to flow than to do it “right”.
- Applying deliberate discovery significantly reduces rework, and helps us get beyond 2nd Order Ignorance (not knowing what we don’t know) to asking the right questions.
And practically:
- A test is a sentence describing the next behaviour in which you are interested.
- Scenarios relate directly to the User Story format
The Scenario Title should say what’s different about this path
Given: should describe all of and no more than the given context-
– Multiple givens are clearly stated with “AND” and sometimes “BUT”
When: the action or event should describe the feature
– Very simple – typically a single call into production code (no ANDs)
Then: should describe all of and no more than the outcome of this path
– Multiple outcomes are clearly stated with “AND” and sometimes “BUT”
So that’s the theory (somewhat condensed)… now to apply it to our stories.
Applying the Concepts
I think one of the problems we had experienced most was simply getting around to writing the scenarios. Feeling the pressure to get them “right” at the start so as to move quickly onto the next feature resulted in a tendency to avoid doing them at all. Up to this point, we hadn’t been creating scenarios as a Scrum team; the developers had created them as part of their Sprint Planning 2 and fleshed them out as they went along. But we were on a mission, so we persevered.
We started with a simple story:
As: A fleet operator
I want: Events coloured according to the event time
So that: I can identify the age of the events
With the following status key:
| Age of event | Colour |
| event age < 30 mins old | Green |
| 30 mins ≥ event age ≥ 1hr | Blue |
| event age ≥ 1 hour | Red |
As a group, we started writing the initial scenario:
Scenario: Event is 30 minutes old
Given: An event is raised at 12:00
And: the current time is 12:30
When: the event is displayed on the map
Then: the location of the event should be displayed in blue
Delving into the Detail
At first this seemed clear enough, but as we discussed the event being raised and the fleet manager watching the screen, we quickly realised our scenario didn’t take time zones into account. The events are all sent from the units in UTC, but the fleet operators viewing the maps have their regional settings as Central African Time (GMT +2.00).
This led to a lengthy discussion around how and when the time zone offset was being applied to the event.
So we changed our scenario as follows:
Scenario: Event is 30 minutes old
Given: An event is raised at 12:00 UTC
And: the current time is 12:30 UTC (14:30 CAT)
When: the event is displayed on the map
Then: the location of the event should be displayed in blue
We expanded our state table to include CAT, and specific detail:
| Event Time | Current time in UTC | Current time in CAT | Colour |
| 12:00 | 12:15 | 14:15 | Green |
| 12:00 | 12:30 | 14:30 | Blue |
| 12:00 | 12:45 | 14:45 | Blue |
| 12:00 | 13:00 | 15:00 | Red |
As we connected the dots between our unspoken assumptions, there was a profound feeling of relief and clarity on how to move forward.
In retrospect, I wonder whether we should have included a check for the users’ regional settings affecting the display – something along the lines of “the fleet manager is viewing the map at 14:30 CAT”?
We might also have benefited from special scenarios for the point when an event should change colour:
Scenario: Event becomes 30 minutes old
Given: An event is raised at 12:00
And: the current time is 12:29 UTC
And: the fleet manager is viewing the map at 14:29 CAT
When: the time changes to 12:30 UTC
Then: the location of the event should be displayed in blue without the page refreshing
The more we thought about it, the more there seemed to be to think about – a both refreshing and daunting concept.
Reflections
Having gone back to the initial reading, I took heart that our learnings echo Liz Keogh’s observations:
- Assume you’ll be wrong at first; trying to get it right first time is a waste and causes procrastination which is further waste.
- Discussing the issue from the perspective of the story’s persona is much easier when the whole team is involved as we have more input on how the different people and applications in the system interact.
- Just having the discussion really did help us understand an important issue we’d been struggling with previously, which was invaluable.
I’m left with the reflection that in software, the words “it goes without saying that …” often
precede some of the most critical assumptions and constraints in our work, and should never go without saying.
It still feels hard to start the BDD discussions but we’ve committed to bringing them into our grooming sessions, so I hope this will be the start of a growing trend of becoming aware of what we know, as well as what we don’t know, and finding the right questions to ask to get us smoothly to Done.
About the author:
Cara Turner is a scrum master and agile coach at KRS. With experience over a wide variety of software projects, she has a particular passion for creating great working environments that meet the complex challenges of software development.