User stories – WHO wants them, WHAT are they, WHY use them?

WHO wants user stories?

Project stakeholders: these individuals want an easy method to pin ideas to the product backlog. With user stories ideas don’t need to be defined in detail – the user story will provide a “placeholder for a conversation”.
The end user: teams that are able to elicit requirements directly from end users can use this technique to facilitate the discussion and documentation of feature requests. What does the user want to do? Why?
Project Manager/Product Owner: when grooming the product backlog – user stories are much easier to prioritise than detailed requirement specifications. User stories provide a non-technical, concise summary for the product team to decide the primacy of a feature.

WHAT are user stories?

Definition: User stories describe the desired interaction/dialogue between a user and the system. User stories provide the user’s rationale for a feature.
Typical format:
- AS A [actor/user role] – this can be referred to as the WHO section. Who wants this feature? The user could be a generic actor (e.g. AS A user of the website), or a specific user role (e.g. AS A frequent business traveller), or even another system (AS A BACS payment system). Actors can be identified by internal discussions within the project team – identifying user roles may require more sophisticated analysis (e.g. profiling activities by the marketing department, transaction analysis, industry segmentations etc).
- I WANT [feature/action] – this can be referred to as the WHAT section. What does the user want? The user will typically want the system to perform a new behaviour e.g. I WANT the ability to track an order, I WANT to pay for orders using an AMEX card, I WANT to cancel an order without any hassle.
- SO THAT [benefit] – this can be referred to as the WHY section. Why does a user want this functionality? This section provides the justification/benefit of the feature.
- Characteristics of good user stories: the INVEST acronym is frequently used to describe attributes of a good user story:
  - Independent
  - Negotiable
  - Valuable / Vertical
  - Estimable
  - Sized Appropriately / Small
  - Testable

WHY use user stories?

Requirements as an emergent property: user stories provide the Business Analyst with a springboard for analysis. A single user story (e.g. AS A price sensitive user, I WANT to be able to cancel my order, SO THAT I do not get charged by the bank for exceeding their overdraft limit) can lead to multiple scenarios for the BA. What is the happy path of this user story? What are the edge cases (e.g. what if some of the items are in the sale)? What are the business rules (e.g. full refunds are only provided up to 3 days from when the transaction was processed)? Requirements should emerge from user stories (not vice versa) – all requirements should have a user justification.
Maintenance of the backlog: the detail of a feature is abstracted a level below user stories. In addition – user stories should have few/no dependencies (refer to the INVEST acronym) – this means that user stories are lightweight additions to the product backlog and are therefore easy to maintain.
Available for discussion: user stories should be understandable by business users/end users/developers/all team members. User stories facilitate cross-role discussions and encourage open communication between various project sillos.
Trees and forests: Working at a detailed level can occasionally mean that some requirements are not identified. User stories provide a way to mitigate the probability that user journeys are missed by the team.