用户故事是什么：User Story 定义、模板与案例

用户故事的定义

用户故事（User Story）是从用户视角描述需求价值的简短陈述，是敏捷开发中替代传统 PRD 的轻量化需求表达方式。用户故事强调用户身份、需求动机与期望价值。

用户故事的三要素

经典格式：作为 [角色]，我想要 [功能]，以便 [价值]

• 角色（Who）：作为某个特定类型的用户
• 需求（What）：我想要某个功能或特性
• 价值（Why）：以便达成某个具体目标

用户故事的 INVEST 原则

• Independent（独立的）：故事之间相互独立，便于排期
• Negotiable（可协商的）：故事不是合同，是协商起点
• Valuable（有价值）：每个故事都要为用户或业务创造价值
• Estimable（可估算的）：故事大小可估算，便于排期
• Small（小的）：故事要足够小，一个迭代内可完成
• Testable（可测试的）：故事要有明确的验收标准

用户故事的常见误区

• 误区一：用户故事只写功能不写价值
• 误区二：用户故事过于庞大（不符合 Small 原则）
• 误区三：用户故事不可测试（缺少验收标准）
• 误区四：把用户故事等同于任务，缺少用户视角
• 误区五：忽视非功能性需求（性能、安全、可用性）

用户故事与 PRD 的关系

• 用户故事：敏捷、轻量、从用户视角出发
• PRD：系统化、详细、面向协作方
• 实践中可组合使用：用户故事 + 补充说明

用户故事的拆分技巧

• 按用户角色拆分：不同用户的需求分开
• 按使用流程拆分：一个完整流程拆为多个步骤
• 按数据复杂度拆分：基础功能与高级功能分开
• 按业务目标拆分：不同业务目标对应不同故事

用户故事地图

用户故事地图（User Story Mapping）是将用户故事按用户旅程组织的可视化工具，由 Jeff Patton 提出。故事地图帮助团队理解用户使用产品的完整流程、识别 MVP 范围。

常见问题

用户故事和 PRD 应该选哪个？

视团队与项目。敏捷团队倾向用户故事；复杂项目倾向 PRD。实践中常组合使用。

用户故事一定要用三要素格式吗？

建议使用。标准化格式便于团队协作与需求评审。

用户故事地图有什么价值？

帮助团队对齐用户旅程、识别 MVP 范围、规划迭代节奏。

用户故事验收标准怎么写？

用 Given-When-Then 格式：给定某个条件，当某个动作发生时，那么某个结果应该出现。

用户故事适用于 B 端产品吗？

适用，但 B 端用户故事要包含角色（决策者、使用方、付费方）的明确区分。