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

User stories are a popular technique for capturing high-level requirements. User stories provide the rationale and basic description of a new feature request. The following format is the most recognizable user story template:

As a <WHO>
I want <WHAT>
So that <WHY>

Agile teams adopting the user story technique often struggle with questions such as: WHO are user stories produced for? WHAT do good user stories look like? WHY maintain user stories instead of more detailed requirement specifications? To answer these questions – I will recycle the who/what/why template of user stories.

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:
  
  1. 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 traveler), 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).
  2. 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.
  3. 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:
  1. Independent
  2. Negotiable
  3. Valuable/Vertical
  4. Estimable
  5. Sized Appropriately/Small
  6. 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 were reduced as part of a promotion)? 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 silos.
• 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.

User stories provide the team with a method to capture and discuss high-level requirements. Good user stories follow the INVEST acronym and provide the user’s justification for a new feature. Within Scrum/Agile teams – user stories provide an abstraction of requirement details – this facilitates maintenance of the backlog and provides the team with a “placeholder for a conversation”.