User Story: 3Cs

The concept of user stories

User stories are a lightweight method for quickly capturing the “who”, “what” and “why” of product requirements. Simply put, user stories are ideas that express the needs that users want. User stories are short, and each element usually contains less than 10 or 15 words. User stories are “to-do” lists that help you identify the steps along the project path. They help ensure that your process, and the resulting product, meet your requirements.

Concept of this kind of thing I like to say the way to understand and explain the word;

user story = user + story = person + story + event

That is, what a person wants to do for what reason, distill out the three elements is who, why, what. from the user perspective is a short description used to confirm the user and user needs.

The three elements of the user story

User stories are used in the software development process as a form of expression to describe requirements. In order to standardize the expression of user stories and facilitate communication, user stories are usually expressed in the following format:

As a <user role>, I want to <complete the activity>, in order to <realize the value>.

A complete user story contains three elements.

1. persona (who?): who wants to use this
2. action (what?): what action to complete
3. Value: (why?) do this and what value can be brought by doing this

Three, 3C principles

The descriptive information of user stories is written on paper cards in a traditional handwritten way, so Ron Jeffries (2001) calls these three aspects 3C:

1. card (Card),
2. conversation (Conversation) and
3. confirmation (Confirmation).

Card: User stories are generally written on small cards with a short description of the story, rules, and completion criteria.

The front of the card contains the description of the story in the format: As a <role>, I want to <complete the activity> in order to <realize the value> describe the need; the back of the card contains the rules and completion criteria for completing the user story in the format: Given…When…Then.

Conversation: The details behind the user story come from communication with the customer or product owner; make sure all parties understand the story correctly.

Confirmation: Confirm that the user story has been completed correctly through acceptance testing.

• Writing general user stories
• What is User Story Mapping?
• How to Manage User Stories with Story Map?
• Prioritize user stories