User Stories: Templates, Acceptance Criteria, and Worked Examples
与謝秀作
A user story describes a small piece of work through the value a user wants to gain. It helps a team discuss why a capability matters before deciding how to build it. Agile Alliance describes stories as functional increments that contribute to product value.
Filling in a sentence is only the beginning. Discuss the user, intended benefit, scope, and conditions for checking the result.
Use a simple template
A common structure is: “As a [user], I want [capability], so that [benefit].” The exact wording is optional; the elements should remain clear.
Element | Fictional application-form example |
|---|---|
User | Someone partway through an application |
Capability | See which input is invalid and how to fix it |
Benefit | Continue without losing existing entries |
Acceptance criteria | The problem and correction are clear, and other entries remain intact |
“Implement error messages” names a task. “Recover and continue the application” provides a basis for choosing useful messages and navigation.
Add testable acceptance criteria
- Submitting with a required field empty identifies the field and missing information.
- Other entered values are retained.
- Correcting the error permits resubmission without creating a duplicate record.
- The user can reach and correct the field using a keyboard.
These are illustrative criteria, not a complete specification for every form. Examine error cases, permissions, measurement, and interaction needs for the actual context.
Acceptance criteria describe expectations for an individual item. The Definition of Done describes the quality state required of the resulting work. Satisfying one story’s behavior does not remove shared testing or quality requirements.
Separate stories, tasks, and the backlog
Term | What it describes | Example |
|---|---|---|
User story | A small user benefit | Recover from an error and continue applying |
Task | Work needed to deliver it | Write copy, change storage behavior, test |
Product Backlog | An ordered set of needed improvements | Stories, investigations, fixes, and other work |
Scrum does not require every backlog item to use the user-story format. See The Scrum Framework for the framework itself.
Split large stories around usable outcomes
“Manage all applications” is too broad to estimate meaningfully. Consider smaller flows such as submitting an application, reviewing its confirmation, and finding an application with a filter.
Splitting only into screen, database, and testing work may leave each item unusable alone. A narrow end-to-end user scenario can be more useful. Check that each slice has a clear benefit, can be verified, and does not create unnecessary dependencies.
Use Story Points and Planning Poker to discuss uncertain estimates. Before choosing work for a Sprint Duration and Planning, confirm the user need, included and excluded scope, acceptance criteria, external dependencies, and a credible route to completion.
Keep supporting detail where it is needed
Technical improvements need not be forced into awkward user-story wording. Explain their effect and how it will be checked. Stories also do not replace necessary designs or constraints; they organize the conversation around value.
Xtrategy’s project management features connect campaign task progress and approval information when the work needs to remain visible in a broader operational plan.