User Story Template

What is a User Story?

A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

A good way to think about a user story is that it is a reminder to have a conversation with your customer, which is another way to say it's a reminder to do some just-in-time analysis. In short, user stories are very slim and high-level requirements artifacts.

User Story is "a concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software)".

Components

User Story Cards have 3 parts:

1. Card - A written description of the user story for planning purposes and as a reminder.
2. Conversation - A section for capturing further information about the user story and details of any conversations.
3. Confirmation - A section to convey what tests will be carried out to confirm the user story is complete and working as expected.

The typical template has 3 parts: the title, the description (or body of the user story), and the acceptance criteria. The title is used to reference the user story and should be kept very short, around 3 to 10 words. The description is where the meat of the user story is kept. It is the only part that can be explained as a reasonable template. The acceptance criteria are used to determine when the user story has met the goal of the user – a sort of test.

User Story Description

As a [user role] I want to [goal] so I can [reason].

For example: As a registered user I want to log in so I can access subscriber-only content.

• Who (user role)
• What (goal)
• Why (reason)
  • gives clarity as to why a feature is useful
  • can influence how a feature should function
  • can give you ideas for other useful features that support the user's goals

User Story Example

How detailed should a User Story be?

User story should be detailed enough for the team to start work from, and further details to be established and clarified at the time of development.

INVEST Principle

• Independent - User Stories should be as independent as possible.
• Negotiable - User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.
• Valuable - User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.
• Estimable - User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.
• Small - User Stories should be small. Not too small. But not too big.
• Testable - User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

Epics

Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point.

Epics are typically lower priority user stories because once the epic works its way towards the top of the work item stack, it is reorganized into smaller ones. It doesn’t make sense to disaggregate a low-priority epic because you’d be investing time on something which you may never get to addressing, unless a portion of the epic is high priority and needs to be teased out. Remember to defer commitment, in this case model on a just-in-time (JIT) basis, to increase your overall productivity.

Themes

A theme is a collection of related user stories. Themes are often used to organize stories into releases or to organize them so that various subteams can work on them.

References:

• New to User Stories? (link)
• Introduction to User Stories (link)
• Introducing User Stories presentation.