concept user story in category BDD

This is an excerpt from Manning's book BDD in Action Second Edition MEAP V04. Login to get full access to this book.

For instance, the first example card, “The one where there is only one possible line”, could be delivered as a user story in its own right. This simple case will let them build up the initial application architecture without too much domain complexity. We could describe this story as follows:

Features and User Stories. In BDD terms, a feature is a piece of software functionality that helps users or other stakeholders achieve some business goal. A feature is not a user story, but it can be described by one or several user stories. A user story is a way of breaking the feature down into more manageable chunks to make them easier to implement and deliver.

For the sake of simplicity and consistency, let’s step through the vocabulary we’ll use throughout the rest of this book. We’ll mainly be dealing with four terms: capabilities, features, user stories, and examples (see Figure 4.3).

Figure 4.3 Features deliver capabilities to stakeholders. We’ll use user stories to plan how we’ll deliver a feature. We’ll use examples to illustrate features and user stories.

User stories are the bread and butter of Agile projects, and they’ve been around, in slightly differing forms, since the origins of Agile. A user story is a short description of something a user or stakeholder would like to achieve, expressed in language that the business can understand. For example, the following user story describes a requirement around forcing users to enter at least a moderately complex password when they register to be a Frequent Flyer member. For this story, you can use a format very similar to the ones used for features earlier on:

Story: Providing a secure password when registering #1
In order to avoid hackers compromising member accounts #1
As the systems administrator #1
I want new members to provide a secure password when they register #1

copy

Agile practitioners are fond of emphasizing that a user story is not actually a requirement, but more a promise to have a conversation with the stakeholders about a requirement. Stories are a little like entries in a to-do list, giving you a general picture of what needs to be done, and reminding you to go ask about the details when you come to implement the story.

This is an excerpt from Manning's book BDD in Action: Behavior-Driven Development for the whole software lifecycle. Login to get full access to this book.

A feature may be detailed enough to work with as is, but often you’ll need to break it up into smaller pieces. In Agile projects, larger features are often broken into user stories, where each story explores a different facet of the problem and is small enough to deliver in a single iteration.

A user story is a way of breaking the feature down into more manageable chunks to make them easier to implement and deliver.

Figure 4.3. Features deliver capabilities to stakeholders. We’ll use user stories to plan how we’ll deliver a feature. We’ll use examples to illustrate features and user stories.