用户故事是什么
用户故事用一句业务语言表达需求：“作为某角色，我希望完成某目标，以便获得某价值”。它的价值不在卡片上的文字，而在于卡片引发的对话与事后确认，因此强调 Card 卡片、Conversation 对话、Confirmation 确认三要素。故事是需求的占位符，细节应在沟通中澄清并沉淀为验收标准，而不是在写卡片时一次性写死。
基本信息
| 句式 | 作为……（角色），我希望……（目标），以便……（价值） |
|---|---|
| 三要素 | Card 卡片、Conversation 对话、Confirmation 确认 |
| 配套检查 | INVEST 六条准则与验收标准 |
| 粒度 | 一个迭代内可完成，能独立演示与验收 |
| 常见载体 | 需求管理工具卡片 + 验收标准 + 相关原型或接口约定 |
示例
示例
作为已登录用户，我希望按订单号查询历史订单，以便核对付款与物流状态。
验收标准：
已知 用户已登录且订单存在
当 用户输入订单号查询
则 返回订单详情与物流节点，且不返回他人数据典型使用场景
- 迭代计划会：用故事清单确认本次做哪些、明确不做什么
- 需求澄清：围绕卡片对话，把规则与例外补成验收标准
- 拆分大需求：按角色或价值路径切成多条可独立交付的故事
- 优先级排序：用“没有它本版是否可用”判断先后
- 验收与演示：以故事为最小交付单元，向业务方逐条演示
- 进度沟通：用已完成故事反映真实价值交付，而非代码行数
反例与改写
| 反例 | 问题 | 改写方向 |
|---|---|---|
| 实现订单查询接口 | 技术任务伪装成故事，丢失角色与价值 | 按订单号查询自己的历史订单 |
| 系统要支持微信支付 | 缺角色与目标，无法判断完成标准 | 作为未持卡用户，我希望用微信完成支付 |
| 优化数据库索引 | 无用户价值，属于技术任务 | 移入技术待办，不再伪装成故事 |
| 重构用户模块并完善文档 | 粒度过大且混入多项工作 | 拆成多条可独立验收的故事 |
故事本身不承载全部细节；需要长期稳定的契约应写入需求库或接口文档并纳入版本管理，避免只存在于某次对话中。
把故事当作需求文档逐字评审，会退化成写规格说明；重点应放在明确角色、价值与验收条件上。