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, with a focus on value and the person who will make use of that value, particularly an external customer.
Start with understanding 'Users'
Traditional product development often starts with user research inspired by design thinking. The ’empathise’ stage attempts to gain a deeper understanding of the people you are designing for. This helps everyone involved in product development to understand people in a particular context:
- What people want
- How they behave
- How they feel and think
This is often considered “UX” work, where project managers engage a UX professional to provide these insights to the team through documentation. In an agile team, however, understanding and involving users is instead a team sport.
When to involve 'users'
User research and engaging with users is often considered “UX” work, where project managers engage a UX professional to provide these insights to the team through documentation. In an agile team, however, understanding and involving users is instead a team sport.
Involving users, doing user research, is done at any time in a Sprint.
In an agile team, these activities are part of backlog management:
- Creating and refining ideas.
- Learning about the product, its use, and the product’s environment.
- Learning about who uses the product and how.
- Learning about and measuring any customer satisfaction gap.
As the Product Owner is accountble for the budget, it’s the Product Owner’s responsibility to invest in learning for the team prior to documenting ideas as User Stories. Empathy Maps are a common way agile teams document their learnings, from which they can easily identify and document stories.
Documenting learnings as User Stories
Now that you’ve got some ideas and knowledge about users, there are three ways agile teams typically write and format this knowledge as a Product Backlog item:
- Three Cs
- Invest
- User Stories
#1: 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 sometimes a large sticky 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?
- Who is it valuable for?
- Why is it valued – by internal stakeholders or external customers?
- When is it needed? Is there a date it is needed by?
- 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.
When to use the 3 Cs
The 3 Cs is great as a reminder or checklist of what is likely needed by the team before the item is ready to go into a Sprint.
#2 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)
When to use INVEST
The 3 Cs is one of the most versitile formats for writing a Product Backlog item. It’s often the first one teams start with until they find a format they’re comfortable with. It provides sufficient structure for a conversation and, if it doesn’t fit on one of these cards, then the idea likely can’t be completed in a single Sprint.
#3: 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.
