What is required? – User Stories supported by Scenarios.
At the beginning of an agile product development or while discussing potential new features, discussions about what is required will take place and be recorded. Traditionally, these requirements might be “captured” in use-cases, spread sheets, or other documents:
Alternatively, user stories may be employed to clearly and succinctly capture the value of potential features:
For example: As a returning customer, I want to log in to the site so that I can access my account. A backlog comprised of a few hundred statements of similar clarity is easy to work with. You don’t need to hold too much information in your working memory, allowing features and releases to be planned and prioritised while reducing the risk that in-depth analysis is done for work that is later dropped.
There will come a point when the commitment to build a feature increases, typically a few weeks before a team plans to begin work on building it. At this time, it is beneficial for a clear understanding to be reached between those providing the requirements and those carrying out the work. Scenarios achieve this by providing specific examples of how the product should behave in different situations:
For example, Correct Login: Given I already have a user account and am on the login screen, when I enter valid credentials, then “successfully logged in” appears for two seconds and I can see the home screen.
Scenarios in this format work best when they form part of the debate between those involved in building the product, and those who have asked for it. Being specific about exactly what will happen after login reduces chances of assumptions filling the void left by vague requirements. Using clear language and limiting the number of examples provided keeps the requirements accessible, reducing the chance of meaning being lost in highly detailed but impenetrable documentation.
How to build it
As work gets closer to being started, the level of detail increases. Items further down the backlog may be very large and teams will need to figure out the best way to break them down. Agile development teams know that it is desirable to deliver small increments that have independent value, which is great in theory but often very difficult to achieve in practice. It will often be very difficult to see how a backlog item can be broken down in such a way that the first part is genuinely valuable.
Scenarios can help with this problem. The act of analysing the intended behaviour of a feature promotes focussed, short and effective discussion and increased understanding of the implementation. Having produced a handful of scenarios, or even just the scenario headings, these can define the boundaries between basic functionality and supplementary scope to be deferred for a later release. For example:
How the product functions
As a product grows in features and complexity, it becomes important to keep track of the features and functionality present. Having used scenarios to negotiate what should be built then how to break down the work, completed scenarios can then be organised to form the documentation for the overall system. Scenarios may be organised by functional area, or features, which would grow with each new increment. For example:
Feature: Create new account
Scenario: Successful account creation
Given I am a new user on the create new user page
When I enter a valid full name, user name and password
Then the “successful user created” page is displayed
Scenario: Requested user name already exists
Given I am a new user on the create new user page
When I enter a full name, user name and password
But The user name already exists
Then A prompt appears offering alternative user name
Scenario: Missing details
Given I am a new user on the create new user page
When I enter a valid full name and user name but no password
Then A prompt appears telling me what I missed
Having existing functionality described clearly can help with analysing future changes, which may not just involve creating new scenarios but modifying existing ones. This makes changes to what was previously asked for explicit and reminds people to have the right conversations.
Knowing when you’re done & ensuring that things still work
In the same way that test-driven development helps engineers write “just enough” code to solve neatly defined technical problems, behaviour-driven development gives engineers a tool to focus on the simplest solution to a well-articulated business need, and to have confidence that they have met the requirements.
The scenarios used to help shape the form of the completed feature may then be used to ensure that the intended functionality is not unintentionally lost with later updates. BDD scenarios form part of the Gherkin pseudo-language, and can be easily integrated into an automated testing package such as Cucumber, Specflow, Lettuce or Behat. With that in place, the documentation describing how the product functions will never go out of date without flagging up a warning every time your code is built. Conversations between customers, stakeholders, the business and software developers are now seamlessly integrated with the engineering practices used to built and maintain the product:
