第3章 用户故事编写与优先级排序
用户故事是敏捷需求管理中最基础、最常用的表达单元，它将真实的用户场景与产品功能需求直接绑定。本章围绕用户故事的标准化编写、质量检查、优先级排序和规模估算四个核心环节展开，帮助产品经理建立从“用户声音”到“可执行需求队列”的完整工作流。全章内容覆盖用户访谈后的需求拆解、方案表达中的故事卡片编写、验收标准的内嵌，以及交付物模板的呈现。
3.1 用户故事标准格式
用户故事采用三段式模板，强制要求写作者同时回答“谁要用”、“要什么”和“为什么”三个关键问题。这种格式天然对齐用户场景与业务问题，确保每一条需求都回溯到真实的用户动机。
| 字段 | 格式指引 | 常见错误 |
|---|---|---|
| As a（用户角色） | 明确具体的一类用户，而非模糊的“用户” | 写成“作为系统管理员”（角色过宽） |
| I want（功能需求） | 描述用户意图，而非技术实现 | 写成“我要调用API接口” |
| So that（业务价值） | 说明该功能解决的业务问题或带来的收益 | 写成“以便功能上线” |
PRD 片段示例：用户故事卡片
以下内容可直接作为 PRD 中用户故事章节的交付物模板。
以下内容可直接作为 PRD 中用户故事章节的交付物模板。
故事编号: US-003
As a 在线购物的注册用户
I want 能够通过手机号找回登录密码
So that 在忘记密码时快速恢复账户访问，不影响购物流程
优先级: Must（P1）
估算: 5 故事点
验收标准:
1. 输入已注册手机号可获取短信验证码
2. 验证码有效期为 5 分钟，60 秒内不可重复发送
3. 验证通过后允许设置新密码
4. 新密码须符合长度≥8 位且包含字母与数字的强度规则
实践要点：用户故事来源于真实的用户访谈。每次访谈后，建议现场把用户原话转化为三段式草稿，再回读给用户确认，这是需求拆解中最有效的闭环验证方式。
3.2 INVEST 原则
INVEST 是检验用户故事质量的六维标准。每一条用户故事在进入优先级排序之前，都应该用这六把尺子逐一测量。不符合要求的用户故事应当被拆分、补充或重写。
| 维度 | 含义 | 检查问题 |
|---|---|---|
| I - Independent | 故事之间相互独立，无依赖 | 是否可以单独交付这个功能而不依赖其他故事？ |
| N - Negotiable | 实现细节可协商，而非硬性规定 | 团队是否有空间讨论具体实现方案？ |
| V - Valuable | 对用户或业务有明确价值 | 用户能感知到这个功能带来的具体好处吗？ |
| E - Estimable | 规模可估算 | 团队能否给出相对靠谱的故事点范围？ |
| S - Small | 足够短小，可在单个迭代内完成 | 能否在 3–5 天内开发完成？是否需要进一步拆分？ |
| T - Testable | 有明确的验收标准，可测试通过 | 是否写清楚了一组可执行的验收条件？ |
常见陷阱：很多团队在编写用户故事时只关注“I want”部分，忽略了“So that”中的价值论证。缺少价值的故事在后续优先级排序中往往被高估或低估，导致资源错配。建议每次编写后强制填写 INVEST 检查表。
3.3 MoSCoW 优先级排序
MoSCoW 方法将需求分为四个等级，帮助产品经理在有限资源下做出清晰的取舍决策。该方法特别适合在多利益相关方场景中达成共识，是需求拆解后进入方案表达前的关键排序工具。
| 类别 | 含义 | 排序标准 | 资源分配参考 |
|---|---|---|---|
| Must（必须有） | 没有这个功能，产品不可发布 | 法律合规、核心流程断裂、用户无法完成任务 | 约占迭代资源的 60% |
| Should（应该有） | 非常重要，但可找到临时替代方案 | 显著提升效率或体验，非致命缺失 | 约占迭代资源的 20% |
| Could（可以有） | 锦上添花，不影响核心目标 | 提升满意度、降低学习成本、增加转化 | 约占迭代资源的 15% |
| Won't（这次不要） | 明确排除在本轮范围之外 | 低价值、高成本、时机未到 | 不分配资源，放入未来清单 |
需求优先级矩阵应用案例：
某电商平台在“找回密码”功能中，将“手机号验证码找回”标为 Must，将“邮箱找回”标为 Should，将“语音验证码”标为 Could，将“人脸识别找回”标为 Won't。迭代结束后用户核心诉求得到满足，Should 和 Could 需求根据剩余容量灵活插入，未发生范围蔓延。
某电商平台在“找回密码”功能中，将“手机号验证码找回”标为 Must，将“邮箱找回”标为 Should，将“语音验证码”标为 Could，将“人脸识别找回”标为 Won't。迭代结束后用户核心诉求得到满足，Should 和 Could 需求根据剩余容量灵活插入，未发生范围蔓延。
3.4 故事点估算
故事点估算使用相对规模而非绝对工时，帮助团队摆脱“小时陷阱”。最常用的标尺是斐波那契数列（1, 2, 3, 5, 8, 13），数字越大代表复杂度与不确定性越高。估算过程本身就是需求拆解深化的过程——当一张故事卡超过 8 点时，几乎一定需要进一步拆分。
| 故事点 | 典型规模参考 | 不确定性等级 | 示例 |
|---|---|---|---|
| 1 | 极简改动，文案或颜色调整 | 几乎为零 | 修改按钮文案 |
| 2 | 简单功能，单个页面内实现 | 低 | 新增表单校验规则 |
| 3 | 常规功能，涉及 2–3 个交互步骤 | 中等 | 手机号验证码发送与校验 |
| 5 | 较复杂功能，涉及多个模块或数据流转 | 较高 | 密码找回全流程（含短信、校验、重置） |
| 8 | 复杂功能，跨团队协作或技术探索 | 高 | 集成第三方短信服务商 |
| 13 | 史诗级故事，必须拆分 | 极高 | 完整的用户账户安全体系 |
估算会议最佳实践：每次迭代规划前，产品经理准备已通过 INVEST 检查的用户故事卡片，团队使用“规划扑克”同时出牌。若最大最小估算相差超过 2 倍，须由持牌人分别说明理由，然后重新出牌，直至收敛。这一过程同时完成了需求拆解、风险识别和知识共享。
验收检查表示例：
完成优先级排序和故事点估算后，可用下表逐条确认每个用户故事的完备性，再进入原型对齐阶段。
完成优先级排序和故事点估算后，可用下表逐条确认每个用户故事的完备性，再进入原型对齐阶段。
验收检查表（每一条用户故事）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
☐ 三段式格式完整（As a / I want / So that）
☐ INVEST 六维度全部通过
☐ MoSCoW 优先级已标定
☐ 故事点数值已与团队达成一致
☐ 验收条件可量化、可测试
☐ 关联的原型界面编号已标注下图将本章四个核心知识点整合为一个端到端的工作流：从用户故事编写开始，经过 INVEST 质量检查、故事点估算、MoSCoW 优先级排序，最终输出可进入迭代规划的需求队列。该流程与 PRD 编写中原型对齐、验收标准定义等环节紧密衔接。
SVG 图使用指引：该工作流图可直接嵌入 PRD 文档的“需求管理流程”章节，作为团队共识的可视化契约。每个节点对应的详细内容（用户故事卡片、INVEST 检查表、MoSCoW 矩阵、估算记录）均可作为附录链接或子章节引用。