User Stories
User Stories are quite common across many Agile implementations and are used as work items and placeholders for features that are to be built, often used in conjunction with a Scrum Product Backlog or Kanban Card Wall, and used for Story Mapping.
Conversation Reminder
User stories were always intended as conversation reminders, in that, the name “User Story” relates to how they are used in conversation rather than how they are written.
The first value in the Agile Manifesto describes “Individuals and Interactions over Processes and Tools”, hence User Stories are intended to bring people together to interact and discover what the feature needs to be, rather than as a replacement for written requirements.
Structure
Most User Stories will have a name or index number for easy reference and may also have sizing or estimates to indicate the amount of effort to complete them. A common format for the main bod of User Stories:
- As A <Actor / Recipient>
- I Want <Some Feature>
- So That <Reason / Context>
An additional section is also added to cover the Acceptance Criteria:
Acceptance Criteria: <I Know It’s Done When … >
Gherkin Format
User Stories that are used for Behaviour Driven Development (BDD) practices often employ the Gherkin format for the acceptance criteria rather than unstructured statements:
- Given <Some Pre-condition>
- When <Some Action>
- Then <Expected Outcome>
This provides a set of testable expectations in the User Story that can then be used for feature definitions and generating step definitions.
Granularity
User Stories should also be at an appropriate level, too high such as a Use Case for example, and they will be quite meaningless and take a long time for a team to complete them. Too detailed, and this will replace the conversation with written assumptions about what the feature should be. Good user stories are somewhere between the high level of a Use Case and the detail of a business requirement, and should relate to a work objective or feature to be delivered. Initially, it is quite normal for User Stories to be quite high level, as we don’t know very much about them. Over time, however, User Stories may start to be broken down and split into smaller User Stories that are more consumable by a team as more is known about the item or feature.
Testable
User Stories should relate to a feature or item to be delivered, and a good validity check is to ask it is testable. For example, if a User Story that states “As a User I want the web page to be easy to use so that it isn’t too complicated,” is going to be difficult to deliver as a discrete piece or work and harder to test in an objective sense. A User Story that states “As a researcher I want to search for web pages that match my criteria,” is more defined as a work item that can be tested and evaluated.
Technical Items
User Stories do not have to be just about the user, they can also be for architectural changes or other technical work objectives to be delivered. A good Product Backlog will have a range of User Stories that consider different user segments as well as technical items to be delivered as well, such as improvements to remove Technical Debt for example.
Epics
Epics are usually large features or categories of User Stories and are often used to provide a higher level context for a group of User Stories.
Used in Story Mapping for example, Epics are normally used to indicate the backbone of the Story Map and the main high level feature set. They are then broken down into multiple User Stories as granular work items under each Epic.