User stories are the smallest units of user functionality in agile which can be delivered in one agile sprint. A user story must deliver particular value to the user and must be describable in simple language that outlines the desired outcome.
User stories are not mini-use cases. They are not containers for use case information and they are not system-dependent contracts with complete or detailed specifications.
The Foundation
At Aspirent, we believe that strong and effective user stories are the essential foundation to executing agile. User stories are brief stories which begin a conversation between the Product Owner and the Team. If stories are too detailed, too prescriptive or too vague, they will hinder useful conversation. When the conversation fails, agile fails.
A user story is only part of the story!
User stories are like chapters in a book. They consist of descriptions and conversations and they fit with other chapters to form a larger narrative and theme.
Hierarchy
- Theme
- Epic
- User Stories
- Acceptance Criteria
- Tasks
What are the parts of a user story?
- Story Card – A written description of the user story for planning purposes and as a reminder
- Conversation – A section for capturing further information about the user story and details of any conversations
- Confirmation – A section to convey what tests will be carried out to confirm the user story is complete and working as expected
How Detailed should a user story be?
Detailed enough for the team to begin work, and further details to be established and clarified at the time of development.
Acceptance
The secret to an effective user story is in the definition of robust and illustrative acceptance criteria. Aspirent’s 5 rules defining acceptance criteria:
- Acceptance criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or – in the case of system level functionality – the consuming system.
- Acceptance criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the epic, feature, and story level.
- Acceptance criteria constitute our definition of done
- Acceptance criteria are the Product Owner’s expectations on what will be delivered
- Acceptance criteria can include:
- Functionality that the system will perform
- Interface look and feel (wireframes, prototypes)
- Links to necessary documentation (e.g. SOX compliance documentation)
The Conversation
User stories are conversation starters for the Product Owner and the Team and it is crucial that everyone is a part of the same conversation and are speaking the same language. Each agile team must:
- Establish a common story hierarchy & structure of themes -> epics -> stories
- Establish standards of practice for story size and contents
- Define a common language for acceptance criteria
- Confirm how and who will use “Tasks” within the Stories
- Communicate and govern the quality of stories during backlog grooming and sprint planning processes
– Brent Collins, Founding Partner
