What's in a story?
The following text is a translation of the article "What's in a story" by Dan North & Associates. The original author writes in the first person from his own perspective. The text has been translated to the best of our knowledge and belief. Note: We have described the technical term storytelling for marketing here.
What makes a story?
Behavior-driven development (BDD) is a method that goes from the outside in: it starts on the outside with the identification of business goals or results and then moves down to a feature set (collection of functions) that is intended to achieve these results. Each feature (function) is captured as a "story" that defines the scope of the feature based on its acceptance criteria. This article introduces the BDD approach to defining and identifying stories and their acceptance criteria.
Introduction
Software development is about writing software to achieve business goals. This sounds obvious, but often political or other environmental factors keep us from remembering this fact. Sometimes software development seems to be there to produce "optimistic reports" or something else to keep senior management happy. Or simply to show "employment" to keep employees in bread and butter - but that's another topic.
Usually business goals are too broad and opaque to be used directly for software development - where to start if the goal is "save 5% of operating costs"? So you need better defined requirements to get started.
Behavior-driven development (BDD) means that you can easily and effectively turn the idea of a requirement into implemented, tested and production-ready code. This assumes that the requirement is specific enough to make it clear to everyone exactly what it is about. To achieve this, you need a way to describe a requirement so that all stakeholders - business people, analysts, developers and testers - have a common, equal understanding of the scope of the task. From this basis, they can jointly define when a task is "done" and avoid misunderstandings.
This is where the story comes into play. It needs to be a description of the requirement and the business benefit and contain a set of criteria that all parties agree is "done". This is a more rigorous definition than in other agile methods. Here it is variously described as a "promise after a conversation" or a "description of a feature".
The structure of a story
BDD has a story structure. This is not mandatory - you can use a different story format and still develop behavior-driven - but this structure is presented here because it has proven useful in many projects of all shapes and sizes. Your story should contain at least all the elements described in the template. The story template looks like this:
Title (one line short description of the story)
Explanatory:
As a [role] (as ... [role])
I want [feature] (I want ... [feature])
So that [benefit] (in order to, because ... [benefit])
Acceptance criteria: (paraphrased as scenarios)
Scenario: Title (Scenario: Title)
Given [context] (Given, preceded by fact [context])
And [more context] (And [more context])
When [event] (When [event])
Then [outcome] (Then [result, goal])
And [another outcome] (And [another outcome, goal])
Scenario: ...Remember that stories are usually written in English.
Story-telling
A story should be the result of a discussion between different stakeholders. A business analyst talks to a stakeholder about a feature or requirement and helps to frame it in a story. Then a tester will help define the scope of the story (in terms of acceptance criteria) by deciding which scenarios are useful or less useful. An engineer will provide an estimate of the amount of work required for this story and present alternative approaches. Many great systems come not only from the people who developed them, but also from those who first asked for them.
It's all an iterative process. A stakeholder may have an idea or vision of a feature, but usually has no idea how much work it will take or who will be responsible for that work. With the support of the technical and testing experts, stakeholders will understand the cost-benefit ratio of each scenario and be able to make a decision on whether they really want a feature or not. Of course, this will be balanced against the other requirements: Does it make sense to cover more edge cases in this story, or should you move on to the next story?
Sometimes the development team simply won't know enough to do an effort estimation. In this case, they will decide to do more research work. This task, which is not aimed at delivering a product but at providing answers to detailed questions about the requirement, is called a "spike". [Note: Only then will it be possible to estimate the effort involved and thus the cost-benefit ratio or make it manageable].
Characteristics of a good story
In the following, the requirements for cash withdrawal at an ATM are defined as an example (note: stories are written in English):
Story: Account Holder withdraws cash As an Account Holder [role] I want to withdraw cash from an ATM [feature] So that I can get money when the bank is closed [benefit] Scenario 1: Account has sufficient funds Given the account balance is \$100 And the card is valid And the machine contains enough money When the Account Holder requests \$20 Then the ATM should dispense \$20 And the account balance should be \$80 And the card should be returned Scenario 2: Account has insufficient funds Given the account balance is \$10 And the card is valid And the machine contains enough money When the Account Holder requests \$20 Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should be \$20 And the card should be returned Scenario 3: Card has been disabled Given the card is disabled When the Account Holder requests \$20 Then the ATM should retain the card And the ATM should say the card has been retained Scenario 4: The ATM has insufficient funds ...
As you can see, there are a variety of scenarios to consider. Some have to do with the account balance, others with the card itself, and still others with the ATM itself. Let's "unravel" the story to decide if it fits.
The story title should describe an activity.
The title of the story, "Account Holder withdraws cash", describes the activity of cash withdrawal by the account holder. Before this feature can be implemented, the account holder will not be able to withdraw money from the ATM. As soon as the feature is available, this will be possible. This gives an obvious starting point for deciding what "done" means.
If the title was "Account Management" or "ATM Behavior", you would have to look deeper to understand when the job is done and the framework would not be clear. "Account management", for example, could be associated with salary application and "ATM behavior" could include the PIN change. The story title should always describe the current behavior of the user or system.
The explanation should include a role, a feature and a benefit
The template "As a [role] I want [feature] so that [benefit]" has a number of advantages. By specifying the role within the statement, you know who to talk to about the feature. A clear benefit means that the story writer understands why you want this feature.
It gets interesting when you find out that the feature doesn't really deliver the benefit you attribute to it. This usually means that you are missing a story: although there is a story with the current feature, it brings a different benefit. But the actual story, for which you need another feature that brings the described benefit, is still "hidden".
The example story above tells us that there is an account holder who wants a feature. This tells us where to start investigating what it needs to be able to do.
The scenario title should make it clear what sets the scenario apart from the others
You should be able to line up the scenarios side by side and identify their differences just by looking at their titles. In the example above, you can see that the scenario descriptions only provide information about what is different in each scenario. You do not need to describe "an account holder wants to withdraw money from an unfunded account and receives the response that the transaction cannot be carried out". The title makes it obvious if this is the desired scenario compared to the others.
The scenario should be described by Givens, Whens and Thens
This is the biggest change that teams experience when using BDD for the first time. By the simple fact that users, analysts, testers and developers adopt the vocabulary of "Given, When and Then", they learn that a world of ambiguity disappears.
Not all scenarios are so simple: some are more of a sequence of events: Given is [a context], if I [do something], then [this happens], if I [do something else]. then [something new happens] etc. One example is a program wizard where you are guided through a sequence of screens to create a complex data model. This is perfect for combining sequences of events and results, as long as you get into the habit of thinking in these terms.
One interesting change that emerges is that the quality of the conversation increases. You will quickly notice if you have forgotten a (presupposing) given ("of course the account is overdrawn") or have not verified a result/goal ("of course the cardholder will get his card back"). In one project known to [the author], the lead developer reported that analysts and developers were talking past each other, but he didn't know how to demonstrate this to them. A few days after Given/When/Then was introduced, he could see that the quality of their interactions had increased dramatically.
Givens should contain all the context they need and nothing more.
Any superfluous givens or prefaced facts are distracting as they make it harder for someone watching this story for the first time to recognize what is important to them. Regardless of whether it's from the technical or business side. At the same time, all missing givens lead to assumptions. If you can achieve a different result than what is stated in the existing Givens, something must be missing.
In this example, the first scenario says something about the account balance, the card and the ATM itself. All these elements are necessary to define the scenario. In the third scenario, nothing is said about the account balance or whether the machine contains money. This implies that the card is retained, regardless of the balance or status of the ATM.
The event should describe the feature
The event itself should be very simple, typically a single call in the code. As discussed above, some scenarios are more complicated than the example, but mostly the scenarios of a story will revolve around a single event. They will only differ in context (givens) and the associated expected outcomes.
The story should be short enough to fit into one iteration
There are no hard and fast rules to follow as long as you can break everything down into understandable "bites". As a general rule, if there are more than five or six scenarios, a story can probably be broken down into several. Similar scenarios can then be grouped together.
At this point, it is not possible to say how many more scenarios there are for this story in the ATM example, but there are probably a few more. Basically, there are three pivotal points in this story, namely the account balance, the status of the card and the status of the ATM. You could go into more detail with the card: What if it has expired, so you can't use it to withdraw money, but the machine returns it anyway? What if the machine cancels the transaction in the middle? What if the account has an overdraft facility?
It would then be better to break the story down into different, smaller stories:
- The account holder withdraws money (assumption: machine works and card is valid)
- The account holder withdraws money with an invalid card (assumption: machine works)
- The account holder withdraws money from a broken machine (assumption: the card is valid)
Even if this seems artificial, this approach allows progress to be demonstrated in business terms and provides more data points that can be tracked. It is important to always break the story down along business lines through scenarios (and make the assumptions explicit) rather than aligning it with technical structures (e.g. develop databases in this iteration and user interface in the next...). This is the only way for non-technical stakeholders to see visible progress in their own terms, rather than just taking your word for it.
How does the story differ from use cases?
There are use cases and there are use cases. The original author of the English article describes being a big fan of Alistair Cockburn's description of use cases, as opposed to the over-developed versions he has encountered in various other projects. However, as he has little experience with use case-driven projects, he will leave it to others to draw comparisons here.
He agrees with Cockburn's process of starting with low precision of an outcome or goal and working through to higher precision by building in more and more scenarios as you progress. In BDD, this would mean starting with the business goals and working in high-functioning areas to dive into specific stories with acceptance criteria.
In reality, it doesn't matter how your requirements identification and elicitation process works. It's fine to write requirements documents to help you organize your thoughts. What is not okay is to distribute these documents as if they contain all your thoughts, because they do not. Instead, put your requirements document or stack of use cases to the side and start defining stories from business goals, confident that all your hard work will result in you having all the answers in your head - or at least a good enough understanding to paraphrase the work as you see it right now.
Summary
BDD uses a story as the basic unit of functionality and therefore development. The acceptance criteria are an intrinsic part of the story - they define the scope of the behavior and lead to a common definition of "done". They are also used as a basis for estimating when to start planning.
Most importantly, the stories are a result of meetings between all project stakeholders. BDD is much more about the interaction between different people in the project than about the results of the development process.
Note: arocom uses Behat Tests (BDD) for all projects, including the reach portal haustec.de.
