User Story Template

---
title: "User Story Template"
methodology: "universal"
complexity: "advanced"
owner: "mirichard"
updated: "2026-09-19"
primary_principles: ["value-focus", "quality-by-design"]
secondary_principles: ["stakeholder-engagement"]
principle_rationale: "Expresses one user need through a shared conversation record with testable acceptance criteria and explicit dependencies."
---

# User Story Template

## When to Use

- During backlog refinement when one user need requires a small, testable conversation record.
- When the team must agree acceptance criteria, dependencies, and useful story splitting.

## When NOT to Use

- To replace stakeholder conversation with a rigid sentence format.
- Do not treat completed metadata or a filled checklist as evidence that the underlying work is done. See [Metadata theater](../../../../docs/principles/anti-patterns.md#metadata-theater).

## Pairs Well With

- [Backlog Refinement Template](../../../../domains/team/role-based-toolkits/scrum-master/agile-ceremonies/backlog-refinement-template.md).
- [Requirements Traceability Matrix Template](../../../../domains/delivery/templates/traditional/Traditional/Process_Groups/Executing/requirements_traceability_matrix_template.md).

Selection context: Uncertainty domain; universal methodology; advanced complexity. Match the situations above to project phase, risk, team size, and industry using the [decision-engine context model](../../../../meta/architecture-research/800-801-context-assessment-model.md).

## Story Information
- **Story ID**: [ID]
- **Epic**: [Epic Name/ID]
- **Priority**: [High/Medium/Low/Critical]
- **Estimate**: [Story Points/Hours]
- **Product Owner**: [Name]

## User Story
**As a** [type of user]  
**I want** [some goal or objective]  
**So that** [some reason or benefit]

## Acceptance Criteria
Using the Given-When-Then format:

### Scenario 1: [Scenario Name]
**Given** [initial context or setup]  
**When** [specific action or event]  
**Then** [expected outcome or result]

### Scenario 2: [Scenario Name]
**Given** [initial context or setup]  
**When** [specific action or event]  
**Then** [expected outcome or result]

### Scenario 3: [Scenario Name]
**Given** [initial context or setup]  
**When** [specific action or event]  
**Then** [expected outcome or result]

## Definition of Ready Checklist

This is an optional team working agreement, not a Scrum requirement. Tailor it to support refinement rather than create an approval handoff.
- [ ] User story is clearly written and understandable
- [ ] Acceptance criteria are defined and testable
- [ ] Story is estimated by the development team
- [ ] Dependencies are identified and managed
- [ ] UI/UX mockups or wireframes available (if applicable)
- [ ] Performance criteria defined (if applicable)
- [ ] Security requirements identified (if applicable)
- [ ] Compliance requirements noted (if applicable)

## Definition of Done Checklist

The items below are examples for a software product. Align them with the product Definition of Done; acceptance criteria describe this story, while the Definition of Done defines the quality of the Increment.
- [ ] Code is complete and follows coding standards
- [ ] Unit tests written and passing
- [ ] Integration tests passing
- [ ] Code reviewed and approved
- [ ] Acceptance criteria validated
- [ ] UI/UX review completed (if applicable)
- [ ] Performance requirements met
- [ ] Security review completed (if applicable)
- [ ] Documentation updated
- [ ] Required product acceptance evidence recorded; any organizational approval is separate from meeting the Definition of Done

## Additional Information

### Business Value
[Explain the business value and why this story is important]

### User Impact
[Describe how this will impact the user experience]

### Technical Notes
[Any technical considerations, constraints, or dependencies]

### Design Notes
[Links to designs, mockups, or UI specifications]

### Dependencies
- [Dependency 1]: [Description]
- [Dependency 2]: [Description]

### Risks and Assumptions
- **Risks**: [Any risks associated with this story]
- **Assumptions**: [Any assumptions being made]

## Testing Strategy

### Test Scenarios
1. **Happy Path**: [Description of main success scenario]
2. **Edge Cases**: [Description of edge cases to test]
3. **Error Conditions**: [Description of error scenarios]
4. **Performance**: [Performance testing requirements]

### Test Data Requirements
[Any specific test data needed for validation]

## Conversation Notes
[Space for ongoing conversation and clarification between team members]

### Questions and Clarifications
- [Question 1]: [Answer/Status]
- [Question 2]: [Answer/Status]

### Decisions Made
- [Decision 1]: [Date and rationale]
- [Decision 2]: [Date and rationale]

## Story Splitting (if needed)
If this story is too large, consider splitting into:
1. [Smaller story 1]
2. [Smaller story 2]
3. [Smaller story 3]

## Related Stories
- **Parent Epic**: [Link to epic]
- **Related Stories**: [Links to related stories]
- **Follow-up Stories**: [Stories that depend on this one]

## Metrics and Success Criteria
- **Key Metric**: [What will be measured]
- **Success Criteria**: [How we'll know this is successful]
- **Measurement Method**: [How the metric will be tracked]

---

**Created by**: [Product Owner Name]  
**Date Created**: [Date]  
**Last Updated**: [Date]  
**Status**: [To Do/In Progress/Testing/Done]

*Comprehensive user story documentation for agile development*


Framework reference: [Scrum Guide, November 2020](https://scrumguides.org/scrum-guide.html).