deliver-user-stories

用户故事

用户故事是从用户视角简洁描述功能的内容。它们说明谁需要某项功能、需要什么以及原因，而不规定如何实现。好的用户故事能帮助团队将大型功能拆分为可估算、可交付的增量，同时始终聚焦于用户价值。

适用场景

• PRD 获批后，拆分功能以供实施时
• 在迭代规划期间，创建可执行的工作项时
• 为工程团队编写工单时
• 以易于理解的方式向利益相关方传达需求时
• 根据用户价值确定待办事项的优先级时

不适用场景

• 你需要针对单个故事或切片，深入且可供 QA 使用的 Given/When/Then 覆盖范围 -> 使用 deliver-acceptance-criteria
• 你需要涵盖整个功能的边界条件和失败场景清单 -> 使用 deliver-edge-cases
• 功能本身尚未明确 -> 先使用 deliver-prd；故事应追溯到已记录的需求
• 你需要整理需求细化会议的结果（估算、范围决策、未解决问题） -> 使用 iterate-refinement-notes

说明

收到编写用户故事的请求时，请遵循以下步骤：

1. 了解功能背景 查看 PRD 或功能说明。了解总体目标、目标用户和范围边界。用户故事应追溯到已记录的需求。

2. 确定用户角色 确定哪些用户会与此功能交互。每个故事都应针对特定角色编写，而不是面向泛泛的“用户”。不同角色可能需要针对同一功能编写不同的故事。

3. 按用户目标拆分 将功能拆解为不同的用户目标。每个故事都应交付一项完整且有价值的能力——也就是故事完成后，用户实际能够做到的事情。

4. 编写故事陈述 使用以下格式：“作为一名[角色]，我想要[操作]，以便[收益]。”收益部分至关重要——它说明了这件事的重要性，也有助于确定优先级。

5. 定义验收标准 使用 Given/When/Then 格式编写具体且可测试的标准。验收标准用于定义“完成”——如果所有标准都通过，该故事就算完成。

6. 应用 INVEST 标准 根据 INVEST 验证每个故事：Independent（独立）、Negotiable（可协商）、Valuable（有价值）、Estimable（可估算）、Small（规模小）、Testable（可测试）。修改不符合这些标准的故事。

7. 补充背景和备注 包含相关的设计参考、技术考量和依赖项。这些内容有助于实施人员全面了解情况。

输出格式

使用 references/TEMPLATE.md 中的模板来组织输出。完整的输出应针对每个故事包含：故事标题；用户故事陈述；背景与说明；验收标准；设计备注；技术备注；依赖项；范围外事项；以及仍未解决的问题。对于包含多个故事的文档，请按示例所示，在每个故事的标题下嵌套这些部分。

质量检查清单

最终定稿前，请确认：

• 每个故事都符合“作为一名……我想要……以便……”的格式
• 故事彼此独立（可以按任意顺序构建）
• 验收标准采用 Given/When/Then 格式
• 每条标准都可测试（有人能够验证通过或失败）
• 故事规模足够小，可以在一个迭代中完成
• 故事陈述中不包含实现细节
• 收益部分说明了这件事对用户的重要性

示例

请参阅 references/EXAMPLE.md 中已完成的示例。