Way of Working.

Capturing Requirements as stories and epics

How to write epics and stories to capture the requirements of a project.


The capturing of requirements enables the team to achieve a shared understanding of what needs to be built. A strategy for capturing these requirements is to understand the user intent through epics and user stories, which are then captured and maintained in a requirements backlog.

Image

Epics

An epic is a high-level theme or feature that is used to categorise related stories.
An epic contains the following information:

  • Summary
  • User personas involved
  • Acceptance criteria for each persona

Example

A bicycle sharing app might include the following epic:
Summary: Browse bicycles
Description: View and filter nearby bicycles.
Personas: Users
Scope: When I want to find a bicycle to ride, I can see nearby bicycles and filter them based on my wants and needs.
Benefits: Users can view all available bicycles that suit their criteria and are walking distance from them.
Acceptance criteria:

  • Users can see bicycles near them on a map view.
  • Users can filter bicycles.
  • Users can zoom and move the map to find more bicycles.

Assumptions

  • Only registered users can see nearby bicycles.

Stories

A story is a fine-grained requirement, written from a user’s perspective. Each story belongs to only one epic. A story is the classification of tasks which are delivered during development, so they must be small enough to be completed within one iteration (i.e. you must be able to build it in less than 2 weeks).

A story contains the following information:

  • User story: As a [user persona] I want to [do something], so that [reason for task].
  • Background of story
  • Acceptance criteria
  • Implementation notes

Example

Within the \“Browse bicycles\” epic, there may be the following user story:
Summary: Filter bicycles
User story: As a user, I want to be able to filter nearby bicycles so I can find one that fits my criteria.
Background: This is how the user will locate bicycles that fit their specific criteria.
Acceptance criteria:

  • Users can search for bicycles based on a minimum and maximum hourly rate.
  • Users can search for bicycles based on what kind of gears the bicycle has.
  • Users can search for bicycles based on whether it has a basket, and what type.
  • Users can easily unset filters.

Implementation notes:

  • An inline loader required when fetching.
  • Investigate how different mapping tools will render this information.
  • Should the map change its orientation / zoom based on how many bikes are available after filtering?

Helpful resources

Last updated: 27 August 2020


Related articles