User Story

User Stories are the State-of-the-Art way to describe requirements in the Product Backlog.

They should not have a technical focus, but focus on the users/customers needs.

User Stories must be easy to understand for everyone in the team as well as for stakeholders.

You normally write a User Story in one sentence build in the following format:

1. As a user/guest/member/admin/… [actor]
2. I want … [action]
3. so that … [achievement]

So WHO wants WHAT and WHY.

Size

A perfect size of a user story is a story that can be implemented within 1-3 days.

Acceptance Criteria

Every User Story needs a defined Acceptance Criteria.

When you use cards, you can simply write the User Story on the front side and the Acceptance Criteria on the Backside.

INVEST Priciple for GOOD User Stories

• Independent (I)
  is not depending on another User Story
• Negotiable (N)
  is a basis for collaborative refinement
• Valuable (V)
  is valueable for users, customers or contracting authorities
• Estimatable (E)
  has an estimatable effort (by Developement Team through Story Points)
• Small (S)
  is small enough that you don’t need to split it further
• Testable (T)
  can be tested

Splitting in tasks

The Development Team estimates the time needed to implement the User Story within a Sprint. They also derivate several technical tasks for each story.

Epics

Big user stories that still need to be decomposed are epics and groups of related stories can be bundled in epics.

User Story Maps

A story map is a construct where epics are placed next to each other and the related stories are below, ordered by priority.