I’m hearing of more and more agile teams using Behaviour Driven Development (BDD) as a way to specify the acceptance criteria for user stories. I hadn’t realised how widespread it was getting until I attended two separate talks on it at BA2014 this week (in particular, at the BBC and Aviva).
With each new technique comes a learning curve, both for individuals and for the industry as a whole. The technique matures as people work out how best to apply it.
But there’s good news for anyone learning to use BDD. The technique is already mature, and there’s a body of knowledge out there on how to write BDD scenarios. It’s just that people weren’t calling them BDD scenarios. They were calling them Use Cases.
What is Behaviour Driven Development?
BDD is a technique for specifying the behaviour of an IT system under development, in a way that can be understood by business users, developers and testers alike.
BDD involves writing a number of scenarios that describe how the system behaves under various conditions. The scenarios are normally written using “gherkin” notation as follows:
GIVEN <a set of preconditions>
WHEN <user action>
THEN <system response>
[AND WHEN <user’s next action>
THEN <system response>]
For example,
GIVEN the user has an active account
WHEN the user requests to log in
THEN the system asks the user for their login details
WHEN the user enters their username and password (correctly)
THEN the system logs the user in
AND the system displays the welcome page
Agile enthusiasts have got really excited about BDD and with good reason. It has a number of very clear benefits:
- It provides a very clear an unambiguous description of the expected system behaviour in a language that everyone can understand – plain English
- It is easy to convert into an executable, automated test, and hence ties in very nicely with Test Driven Development (TDD)
- The form of words used helps the delivery team to discover edge cases. For example, in the above scenario, the obvious question is: what happens if the user enters the wrong username and/or password? Such questions usually result in further scenarios being identified before development starts, not during, and results in better story size estimates.
The History of BDD
To understand where BDD came from, you need to look back at the history of Agile.
Back in 1999 I remember listening to Kent Beck at OT99 explaining a new technique he had developed called Extreme Programming (XP). He and Ward Cunningham had created XP in response to various problems and frustrations they were experiencing when delivering software. One of their frustrations was with documentation, which they saw as time-consuming and, more importantly, acted as a barrier to richer forms of communication, such as face-to-face conversation, especially when “thrown over the wall”.
So they largely did away with documentation, preferring instead for developers to have a face-to-face conversation with the relevant business stakeholder to understand what should be delivered for a given user story. Documentation was reduced to a stack of hand-written index cards.
And by doing away with the reams of documentation, they also implicitly did away with the people that wrote those documents – the people we now call Business Analysts. At the time I wasn’t a BA, I was a tecchie, so that wasn’t too much of a problem for me :).
XPers quickly recognised that developers needed some way of determining when a story was “done”, so the user story approach was adapted to include acceptance criteria – once the acceptance criteria were met, the story was done. The acceptance criteria for a given story were a non-structured list of things that had to be true for the story to be successful – capabilities, behaviours, business rules, anything relevant to the story.
So, for example:
- User is able to log in
- Incorrect password or user name displays error message
- System displays welcome screen after login
- Passwords must be at least 8 characters
Another key feature of XP is automated testing and, in particular, test driven development (TDD). The first thing a developer does when developing a user story is to write a suite of automated acceptance tests, based on the acceptance criteria for the story. An automated acceptance test is a small program that simulates a user using the system, and checks the system’s responses. If the system responds as expected, the test passes. If not, it fails. Only then do they write the code. Once the code is written, they run the automated tests. If they pass, job done. If not, fix the code and repeat until the tests pass.
Automated acceptance tests are, as mentioned, small programs that test the system behaviour, and they have three types of “commands”:
- Pre-condition commands – preparatory commands that get the system to a state where it is ready to run the test (e.g. navigating the system to the login page)
- User action commands – that enter data into input fields, clicking submit buttons
- Assertion commands – that test that the system has responded as expected (e.g. displaying the welcome page after a successful login)
The problem was that developers struggled to work out what their tests should look like for a given story. What to test and what not to test? How much to test in one go? Where to start in the process?
Dan North and Chris Matts co-created BDD in 2004 as an answer to these problems. BDD scenarios written in plain English are very easily converted into automated tests:
- GIVEN -> pre-condition commands
- WHEN -> user action commands
- THEN -> assertion commends
And so BDD was introduced into the Agile delivery team’s toolkit.
After a while, agile teams started to notice that writing BDD scenarios, and writing them well, takes time and is somewhat of an acquired skill. And at the same time, Business Analysts were trying to work out whether they had a role to play on agile teams.
Business Analysts Are Back in Business
Based on what I heard at BA2014 this week, it sounds like we are now at a point where BAs are back in favour on (some) agile teams, crafting BDD scenarios for developers to convert into automated acceptance tests and build against.
In my view, this is great news. I think BAs do have something to bring to the agile party – not all developers are good at stakeholder communication and not all developers are good at functional design. Many developers I have met are particularly bad at writing specifications in plain English that business users can understand.
The Wheel Re-Invented
The good news for Agile BAs is that writing BDD scenarios is nothing new. Back in 1986, Ivor Jacobson developed a technique for specifying system behaviour which he eventually called Use Cases. The technique was further refined by Alistair Cockburn in his rather splendid book Writing Effective Use Cases.
Use Cases are pretty much identical to BDD scenarios in their purpose and general structure. They are plain English descriptions of the interactions between a system and its users. The syntax and terminology are slightly different from BDD but otherwise they are the same. Here’s an example (annotated to make the point):
PRECONDITIONS: [GIVEN] the user has an active account
MAIN FLOW:
- [WHEN] the user requests to log in
- [THEN] the system asks the user for their login details
- [WHEN] the user enters their username and password (correctly)
- [THEN] the system logs the user in
- [AND] the system displays the welcome page
ALTERNATIVE FLOWS
3a. Incorrect Password
- [WHEN] the user enters their username and password incorrectly
- [THEN] the system displays an error message
- [AND] the system asks the user for their login details again (return to main flow step 2)
I’ve been using a notation that’s a mixture of both formats myself for a few years now in my agile functional specifications.
The particularly good news is that Cockburn’s book tells you pretty much everything you need to know to write good use cases. You could almost take the book and re-name it “Writing Effective BDD Scenarios”. In fact, that would probably be a pretty good money-spinner!
One of the things that Cockburn emphasises is the importance of discovering the edge cases (alternative flows), and how the use case format helps with this. For me, this is the single most useful feature of both use cases and BDD. Cockburn cites it as one of the main reasons why he still uses use cases when everybody else is (or was) writing user stories.
It’s a real shame that Dan Brown didn’t look a bit more into Use Cases when he was developing BDD (there’s an article on his blog from 2007 where he mentions being vaguely aware of use cases – a missed opportunity). BDD has been a great step forward for agile software delivery, but in my view it would have been even bigger if the term “Use Case” had been baked into the Agile lexicon in the way that BDD has.
It’s ironic that XP threw out use cases (and the use case authors – the BAs) and then had to re-invent them (as BDD) and find people to write them again – but this time in a more just-in-time sprinty sort of way. Maybe sometimes it takes an extreme swing in one direction in order to effect change.
Anyway, we are where we are. Things are heading in (what I consider to be) the right direction, even if we’ve had a slightly unhelpful terminology change mid-flight.
Hi Tony
Good to hear that you like the GWT format. As a BA and the co-creator of the format with of GWT (in 2004) with Dan, I can tell you that I was well aware of Use Cases. I had even met Alistair Cockburn several times. Funnily enough, it was on a walk to Alistair’s house that much of the conversation around BDD started.
The goal of BDD was to help non-technical people describe the criteria in a way that did not require the developer to do any translation of the requirements. GWT is a direct mapping to the TDD style with Mocks.
A couple of years after creating the format, Dan and I reflected that it was already covered by the Use Case although the Use Case. I still use Use Cases to investigate some interactions, especially when state is important. I do not necessarily use them to communicate with the development team.
After we came up with the GWT format, Dan focused on the tooling. I focused on how we could use established BA tools ( Domain Models, Use Cases, State Models, etc. ) to generate the examples that we describe with GWT and other approaches. The approach I came up with was called Feature Injection. I gave a workshop on FI at the first European BA conf.
Let me know if you want to know more about how to use Use Cases and other traditional BA tools with Agile and GWT.
Regards
Chris
Hi Chris,
Thanks for your feedback – it’s good to hear it from the horse’s mouth. First of all, credit where credit’s due – I’ve updated the article to reference you as a co-creator of BDD.
It’s interesting to learn that BDD was to some extent inspired by (Cockburn-style) use cases – I guess that goes some way to explaining why they are so similar. Like I mentioned above though, it’s a shame the linkage hasn’t memed its way into the collective consciousness – newcomers to BA may be unaware of the wealth of existing resources, and old hats may be unaware that their use case writing skills are easily transferred to BDD.
It did at least provide for some humour at BA2014 – in the Q&A following a BDD-related session, I decided to put my head above the parapet and point out that GWT scenarios seemed very similar to use cases, fully expecting to be flamed, but the opposite happened – I received several comments (and even tweets) along the lines of “I was thinking the same thing!”. That’s really what inspired me to write the article.
Hi Tony
I find Use Cases are useful in some circumstances. However, there is a big cognitive bias that they introduce that you need to be mindful of, namely they encourage you to work from the start to the finish. Working forwards, we unconsciously destroy options and makes it hard to ensure coverage. Working backwards from value (outcome) -> output/end -> process -> inputs/start means that it is easier to identify options at each stage.
I’d be interested to hear of your experiences with GWT.
Regards
Chris
Hi Chris,
When I talk about using use cases, I’m really thinking about the particular skill of describing system behaviour as a sequence of steps – user does X, system responds with Y – in plain English, and describing the intent, not the mechanics, and identifying the alternative flows. Not necessarily the top-down aspect of use cases.
Here’s how we’re working on my current project (for more details see Business Analyst Designer Method).
Phase 1 (Request): First, a business stakeholder requests a feature (i.e. asks for what they *think* they want). We add the “request” to the product backlog.
Phase 2 (Define): We do 5 whys on the requested feature to get to understand what their underlying objective is (they asked for tea bag, really they are thirsty). Then we generate as many options as possible that meet, or partially meet, the objective (we call it “options engineering”). We do size estimates on the promising options and then select the preferred option (collaboratively with the stakeholder). If the feature is too big, we split it into phases (like splitting an epic into stories) and put each phase as a separate item on the backlog, prioritized separately (this ensures that any “gold plating” is delayed/avoided. We always include a “do nothing” option – because sometimes it turns out that the user didn’t want the thing they thought they wanted, or it was going to cost more than they thought it was worth.
Phase 3 (Design): Assuming phase 1 is still a high priority, we then write the acceptance tests in use case/GWT format. The tests are written with the user objective in mind, as captured in step 2, so hopefully we end up with a set of tests that, together, fulfil the user objective.
Having read what you’ve written on Real Options and Feature Injection, it sounds quite similar – the key point being that we focus on the objective and identify options to fulfil the objective, rather than just building what the customer thought they wanted.
Hi, I’m not sure if I can drop in but as far as I understand one could compare a User Story with a ‘Use Case slice’. Where complete UC’s offer a structured way to document requirements, one sees User Stories being used as vehicles to create work-items to be done by a team in a sprint.
Now, I was thinking to ‘abuse’ tooling for use cases (EA Sparx), possibly it woul be interesting to write down the use case scenario’s in GWT style, then let the tool generate all alternative scenarios and voilá I get all BDD tests whilst keeping them tied together in a nice model. I can also export these scripts to activity diagras as input for discussions. And teammates who do not like a ‘heavy’ Use Case approach might like this donewhat ‘lighter’ approacht, I hope..
This came across my mind because intuïtively I feel like otherwise I miss some overall frame, keeping the GWT scripts together.
Would this approach/way of thinking make sense?
Hi Huub,
It might work, you’d have to give it a try. To be honest I’m not a huge fan of CASE tools these days – I seem to spend more time getting the tool to work than adding real value. We tend to write our BDD scenarios in Jira tickets these days, and just keep the faith that we covered all the alternative flows. At the end of the day, the important thing is to ensure you have the conversation that goes with the BDD scenario, and that everyone is on the same page. DO let me know how you get on.
Hi Hubb,
I came across this excellent thread while investigating a marriage of UC 2.0 Slices to BDD. So I was delighted to see your comment. Notwithstanding the useful advice that focusing on a tool can lead to dragons, I do think that BDD and UC Slices are a match made in heaven. One does not need to fall into the trap of Big Up Front Requirements when doing UC2.0. In fact, in my experience, it ends up being a more ‘disciplined (?)’ version of Story Mapping … which is a very useful collaborative way to scope and prioritize stories… giving the agile teams an overall context and better understanding of the value proposition. The first slices can be derived from a very lightweight bulleted outline of the Use Case… effectively the ‘bones’ of the Use Case (Walking Skeleton). Each UC Slice is equivalent to one User Story. The Slice’s test cases (derived from the scenarios it implements) are akin to Acceptance Criteria. One can convert the slice into a user story or use the slice as a backlog item to be prioritized, sized just like a story. And to allay fears that you have to find all the slices first… you don’t… so it can be a journey of energent understanding.
The benefit, I feel, like story mapping, is that it provides a framework for building up the functional picture, piece by piece… giving everyone a context… and a persistence mechanism for requirements and commensurate tests, iin regulatory environments. Each Slice has test cases associated with the flows and these can naturally be expressed In GWT.
The only thing I struggle with is convincing folks to NOT try and cram all the ‘solution-oriented’ BDD test cases into the Acceptance Criteria prior to Sprint Planning. The Acceptance Criteria needs to reflect the needed outcomes, not the tests for the way the team has decided to implement the needs. The planned slice/story is a promise for a further conversation during the sprint, where other BDDs based on discussions can be flushed out. I say this because I often see teams taking an hour to discuss a story in sprint planning because they are nervous about sizing a story that doesn’t have ALL the requirements up front.
Perhaps, as I think has been alluded to already, Acceptance Criteria becomes redundant if the Use Case scenarios are written in GWT format? Maybe that is a bridge too far at this point.
I am interested to learn from anyone who is using BDD and UC2.0 today.
Thank you for the excellent thread and wisdom.
Finally some sane discussion I bumped into. Thanks for the thread 🙂
I come from Embedded world and now getting adjusted to the IOT.
In my opinion the combination of the behaviour and Usecases make a great recipe for requirement analysis.
As per the definition -> Usecase is a set of actions, which leads to a result, observable outside the system and is of use to one or more stakeholders.
The highlight here is one or more stakeholders. In my world, every stakeholder can come ask for some behaviour from the system. After analysis, I realize that this behavior is some what similar to what the other stakeholder is asking for. Therefore multiple behaviours can terminate to a single functional usecase that the system offers to one or more stakeholders.
Functional usecase in-turn might have multiple scenarios, based on the pre-conditions, post conditions and the alternate path defined.
In future when one of the stakeholder requests a new behaviour, I will anaylse and check if this is already covered in one of my functional usecase.
If exists,
Then I will see which interfaces shall be modified updated and so on
If not,
Then I will check if new functional blocks or new interfaces are to be added
Waiting for your feedback 🙂
Hi Bhim,
There was a time when I used to be as organised as you 🙂 – I don’t really track functional use cases so much any more – I just write stories, add them to the backlog, and then build them in priority order. For each story, before we build it we do tend to think about what a good “solution” would be for the given stakeholder’s need, so we might build something more generalised. Also, if we notice two similar stories still on the backlog we might merge or group them. But that’s about as organised as it gets!
Hi Tony,
Thanks for the reply 🙂
I work in Automotive field and my work involves lots of process adherence => Traceability in particular.
I agree with the method you mentioned for non safety critical system/sw engineering But for automotive software development, I still feel using and Behaviour scenarios and grouping them into functional usecases shall help.
Anyhow, I really got a great insight with this Blog what BDD is! Thanks 🙂