A user story is one way of representing requirements in a Product Backlog. Mike Cohn defines a user story as a simple, clear and short description of customer valued functionality. It is composed of 3 parts: a written description used for planning, conversation to flesh out the details, and tests to determine completeness.
Similarly, Ron Jefferies describes a user story using the 3Cs: Card, Conversation, and Confirmation. Card because traditionally we’ve written the feature description on an index card. Conversation because the user story or card is a place holder for a conversation where we will flesh out the details closer to implementation, and confirmation representing the acceptance criteria that will determine completeness.
A common template used to represent user stories is:
As a type of user,
I can/want to achieve some goal,
so that I can gain some value.
We might also add a title, some notes, assumptions, and constraints, priority and an estimate. This all goes on the front of the card. On the back, we add the acceptance criteria to help further define the feature and clarify expectations.
Example:
To learn more about user stories, check out the entire Art of Storytelling Series:
- What is a User Story?
- Top 5 Advantages of User Stories
- The 6 Attributes of Effective User Stories – INVEST
- Top 3 Reasons to Split a User Story
- What’s the Right Size for a User Story
- Top 5 Techniques for Splitting a User Story
- What’s the Most Important Part of a User Story?
- 9 User Story Smells and Anti-patterns
- The Art of Storytelling – User Story Smells and Anti-patterns Presentation
Reference and recommend resource: User Stories Applied by Mike Cohn
