User Stories

用户故事

User stories are concise descriptions of functionality from the user's perspective. They capture who needs something, what they need, and why . without prescribing how to build it. Good user stories enable teams to break large features into estimable, deliverable increments while maintaining focus on user value.

用户故事是从用户视角出发的功能简要描述。它捕捉了谁需要什么、需要什么以及原因，而不规定如何实现。优质的用户故事能让团队将大型功能拆解为可估算、可交付的增量，同时始终聚焦用户价值。

When to Use

使用场景

After PRD approval, when breaking down features for implementation
During sprint planning to create actionable work items
When writing tickets for engineering teams
When communicating requirements to stakeholders in accessible terms
When prioritizing a backlog based on user value

产品需求文档（PRD）获批后，拆分功能以进行实现时
迭代规划期间创建可执行的工作项时
为技术团队编写工单时
以通俗易懂的方式向利益相关者传达需求时
根据用户价值对产品待办事项进行优先级排序时

Instructions

操作步骤

When asked to create user stories, follow these steps:

Understand the Feature Context Review the PRD or feature description. Understand the overall goal, target users, and scope boundaries. User stories should trace back to documented requirements.
Identify User Personas Determine which users interact with this feature. Each story should be written for a specific persona, not generic "users." Different personas may need different stories for the same feature.
Break Down by User Goal Decompose the feature into distinct user goals. Each story should deliver a complete, valuable capability . something the user can actually do when the story is done.
Write Story Statements Use the format: "As a [persona], I want [action] so that [benefit]." The benefit clause is critical . it explains why this matters and helps prioritize.
Define Acceptance Criteria Write specific, testable criteria using Given/When/Then format. Acceptance criteria define "done" . if all criteria pass, the story is complete.
Apply INVEST Criteria Validate each story against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Revise stories that don't meet these criteria.
Add Context and Notes Include relevant design references, technical considerations, and dependencies. These help implementers understand the full picture.

当需要创建用户故事时，请遵循以下步骤：

理解功能背景 审阅PRD或功能描述。明确总体目标、目标用户和范围边界。用户故事应与已记录的需求保持一致。
识别用户角色 确定哪些用户会与该功能交互。每个故事都应针对特定角色，而非泛泛的“用户”。同一功能针对不同角色可能需要不同的故事。
按用户目标拆分 将功能分解为不同的用户目标。每个故事都应交付完整、有价值的能力——即故事完成后用户实际可以完成的事情。
编写故事陈述 使用格式：“作为[角色]，我想要[操作]，以便[收益]。”收益部分至关重要，它解释了这件事的重要性并有助于优先级排序。
定义验收标准 使用Given/When/Then格式编写具体、可测试的标准。验收标准定义了“完成”——如果所有标准都通过，故事即完成。
应用INVEST准则 根据INVEST准则验证每个故事：独立（Independent）、可协商（Negotiable）、有价值（Valuable）、可估算（Estimable）、小粒度（Small）、可测试（Testable）。修改不符合这些准则的故事。
添加背景和备注 包含相关设计参考、技术考量和依赖关系。这些内容有助于实现者全面理解需求。

Output Format

输出格式

Use the template in

references/TEMPLATE.md

to structure the output.

使用

references/TEMPLATE.md

中的模板来构建输出内容。

Quality Checklist

质量检查清单

Before finalizing, verify:

Each story follows "As a... I want... so that..." format
Stories are independent (can be built in any order)
Acceptance criteria use Given/When/Then format
Each criterion is testable (someone can verify pass/fail)
Stories are small enough to complete in one sprint
No implementation details in the story statement
Benefit clause explains why this matters to the user

最终确定前，请验证：

每个故事遵循“作为...我想要...以便...”的格式
故事是独立的（可以按任意顺序构建）
验收标准使用Given/When/Then格式
每个标准都是可测试的（有人可以验证通过/失败）
故事足够小，可以在一个迭代内完成
故事陈述中没有实现细节
收益部分解释了对用户的重要性

Examples

示例

See

references/EXAMPLE.md

for a completed example.

请查看

references/EXAMPLE.md

中的完整示例。

deliver-user-stories

Original

Translation