User Stories are just one format for writing Product Backlog items. Unlike traditional software requirements, such as Use Cases, Product Backlog items are designed to communicate just enough of the scope of the work for a team in order for them to start work. Importantly, they represent a problem for the team to solve instead of dictating a pre-defined solution.
The "Three Cs"
“Card, Conversation, Confirmation”. This formula by Ron Jeffries [1] captures the components of a well-formed Product Backlog item or User Story.
Card
A “Card” (or often a Post-It note): a physical token giving tangible and durable form to what would otherwise only be an abstraction.
If the Product Backlog item fits on a single index card then it can probably reach Done by the end of a single Sprint.
Conversation
A “conversation” taking place at different time and places during a project between the various people concerned by a given feature of a software product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation.
The conversation addresses questions like:
- What is needed?
- Why is it valued?
- Who is it valuable for?
- When is it needed?
- How will we deliver the work to the Definition of Done?
- How big is the work and will it fit in a Sprint in its current state (or do we need to slice it into smaller pieces so it does fit in the Sprint)?
Confirmation
The “confirmation”: consensus by the team that the objectives and the scope of the User Story is understood.
- After confirmation the team has a solid understanding what exactly we have to do for successfully completing the item.
- The team will organise the work step by step sequentially one after another from beginning to end.
- Each Product Backlog item will likely have some acceptance criteria
- If the Product Backlog item meets all those criteria the team will not need to do any further work on it.
INVEST
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a backlog item.
If the backlog item fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).
Written well, an item in the Product Backlog has the following characteristics:
- “I” ndependent (of all others)
- “N” egotiable (not a specific contract for features)
- “V” aluable (or vertically sliced)
- “E” stimable (to a good approximation)
- “S” mall (so as to fit within an iteration)
- “T” estable (in principle, even if there isn’t a test for it yet)
User Stories
The “User Story” format for writing Product Backlog items was created by Kent Beck as part of Extreme Programming (XP) to encourage a more informal and conversational style of requirements elicitation than long written specifications.
A common way to formulate stories is the “As a … I want … So that …” form.
- “As a” clause refers to who wants the story
- “I want” describes what the functionality is
- “So that” describes why they want this functionality. The “so that” part provides important context to understand to help get from what the end user think they want to providing what they actually need.
The why ultimately provides an indication of value to the Product Owner so they can order the item relative to the others. This helps the Product Owner optimise the value of the work done by the team.
When to use User Stories
The User Story format often gets used for everything, from APIs to team members and even the Product Owner. As a rule of thumb:
- Only use the User Story format when there is a an actual end-user who will benefit from the features you’re developing.
- Don’t use it to reflect the needs of team members, system components and APIs, or the “organisation”. Use the other formats, e.g. the Three Cs, instead.
References
1. 2001: the Card, Conversation, Confirmation model was proposed by Ron Jeffries to distinguish “social” User Stories from “documentary” requirements practices such as Use Cases.
