User Stories - EventideSystems/decidodeck GitHub Wiki
User stories are short, simple descriptions of features of a system - written from the perspective of the person desiring the new functionality.
User stories act as an agile alternative to use cases, defining the intent of a new feature but allowing for refinement or extension within the development process.
User stories start as a conversation - between customers and BAs - and continue as prompt for further conversations between customers, developers and all other stakeholders that occur throughout the discovery, implementation and testing phases for each feature.
While there is no formal definition, user stories often follow this template:
As a <type of user>, I want <some goal> so that <some reason>
Written this way, a user story identifies the actor, the action and business need for each requirement - the 'who', 'what' and 'why' of each new feature.
Writing good user stories is hard, but the INVEST criteria is a useful tool for checking stories against.
Each story should be as independent as possible. Ideally this means that any story can be worked on in any order, allowing stories to be prioritised by the Product Owner.
A story is not a contract, but rather the basis of a conversation. Each story captures the essence of what the users of the system, but the actual result comes out of collaboration between the customer (through the Product Owner), Developers and QA.
A story must deliver value to users of the system. There is often a temptation to remove the ...so that <some reason> portion of a user story, but this runs the risk of describing features with no clear business need. In any case, the story should clearly convey the value of a feature. This is typically from a user's perspective, but can also address the internal value of a feature (e.g. non-functional requirements such as security).
If a story does not have discernible value it should not be done.
A story needs to be estimable so that it can be sized using the Story Points model. If there is a large level of risk, uncertainty or required effort implicit in a user story it's an indicator that the story needs further research or breaking down into smaller stories.
Each story should represent a small enough chunk of work to be valuable (but no smaller). Stories that suggest more than 3 or 4 days of effort should probably be broken down into smaller stories.
Sometimes the best qualifier for a story is "how can I test this?". If a user story has no clear way for QA to verify its correctness the story needs rework or further definition.
Sometimes a standalone story isn't enough to satisfy the needs of the team. Often we need to extend a user story with additional details - for the purposes of being able to estimate, test, or just have clarity on what we are building. To this end, Acceptance Criteria and Scenarios can be used to add a semi-formal definition of what is expected during development.
It's reasonable to add these attributes to a user story throughout the development process. Discoveries made during implementation can be recorded as extended attributes, both as a document of what was built out but also to aid QA. Even during QA, new attributes may be discovered that help with any rework needed. In this way a user story "collects" information about itself throughout the development process.
The business rules or constraints related to a user story can be captured as a set of simple acceptance criteria, one-line statements prefixed by a MUST, MUST NOT, SHOULD, MAY or similar qualifier.
For example:
MUST return results in XML format
MUST NOT allow non-logged in users from accessing the page
SHOULD warn if the user has not completed their profile
The interpretation of qualifying terms follow the accepted definitions declared in the IETF 2119 best practice guide.
It's often useful to describe a user story in terms of the expected behaviour of the system. Scenarios define "slices" of a feature that help build a more complete picture of how a feature is to be used by users.
The Given/When/Then pro forma used in Behavior-Driven Development provides us with a convention to write scenarios in a consistent style.
Scenarios are typically written from perspective of a user, defining preconditions (Given), the user's actions (When) and expected outcomes (Then). Each scenario should define user-perceivable behaviour of the system.
Scenarios can declare general behaviour of the system, or can describe very specific/concrete behaviour, for example:
Scenario: Insufficient credit
Given I have $200 credit in my account
When I try to purchase an item priced at $210
Then I will see the message "Insufficient Credit"
And I will be presented with a offer to top up my credit
Scenarios can also be used to describe the interaction between actors in a system, for example:
Scenario: Add a new user
Given I am logged in an administrator
And I add new user to the system
Then the new user will receive an email inviting them to log into the system
Scenarios can declare specific details if necessary. In the example above we could define the specific user details we expect to capture, e.g.
Given I am logged in an administrator
And I visit the 'new user' page
And I enter the email address for the new user
And I enter the first and last for the new user
And I save the new user
Then the new user will receive an email inviting them to log into the system
NB It is sometimes simpler to describe these sorts of details in terms of Acceptance Criteria. It all depends on what makes sense or adds clarity to a user story.
Scenarios should avoid describing features in terms of the system itself. For example And I will see a warning message is better than And the system will display a warning message. The emphasis should always on what behaviour the user can see.
It is also possible to describe behaviour from the perspective on non-user agents of the system, e.g.
Scenario: Retrieving documents
Given I am registered client application
And I have set my preferred document format to 'XML'
When I request a document from the system
Then I will receive the document in XML format
TDB