第3章 用户故事编写模板：角色‑功能‑价值、验收条件、优先级标注
核心一句话：用户故事是将业务需求转化为可沟通、可估算、可验收的最小需求单元的标准模板，其骨架是“角色—功能—价值”，血肉是验收条件，标签是优先级。
适用场景
- 采用 Scrum / Kanban 等敏捷方法的需求分析环节
- 需要跨角色（业务方、产品、开发、测试）快速对齐需求意图
- 需求粒度需要拆分到可在 1 ~ 3 个迭代内交付的级别
- 验收标准需要与需求描述绑定，避免“做出来才知道对不对”
前置条件
- 已完成用户角色识别（参见第2章 干系人与角色地图）
- 已具备一份初步的“需求意向清单”（可以是痛点列表、Feature 想法或用户反馈）
- 团队已约定优先级分级规则（如 MoSCoW 或 P1 ~ P4）
操作步骤
- 确定角色（Role）——从角色地图中选出该故事的真实执行者，使用“作为<角色>”开头。
- 描述功能（Feature）——用“我想要<功能>”表达用户的操作或系统提供的功能，动词+宾语，避免技术实现细节。
- 声明价值（Value）——用“以便<价值>”说明该功能带来的业务收益或用户痛点解决。
- 编写验收条件（Acceptance Criteria）——采用 Given‑When‑Then 或清单式，定义“做到什么程度才算完成”。
- 标注优先级（Priority）——根据业务价值、风险、依赖关系，给故事打上 P1 ~ P4 或 Must/Should/Could/Won‘t 标签。
模板速记：
“作为 <角色> ，我想要 <功能> ，以便 <价值> 。”
验收条件：Given <上下文> , When <操作> , Then <预期结果> 。
“作为 <角色> ，我想要 <功能> ，以便 <价值> 。”
验收条件：Given <上下文> , When <操作> , Then <预期结果> 。
步骤详细拆解
| 步骤 | 动作 | 示例（图书管理系统） |
|---|---|---|
| 1. 角色 | 从角色地图中选取具体用户类型 | “作为 图书馆管理员” |
| 2. 功能 | 描述系统对外提供的功能点 | “我想要 通过 ISBN 批量导入图书信息” |
| 3. 价值 | 说明该功能解决的业务问题或提升的指标 | “以便 将上架效率从每本 3 分钟降至 10 秒” |
| 4. 验收条件 | Given‑When‑Then 或检查清单 | Given 管理员已登录系统，When 上传含 10 个 ISBN 的 CSV，Then 系统成功导入 10 本图书并返回导入报告 |
| 5. 优先级 | 按价值/紧急度打标签 | P1 (Must have) — 无此功能，管理员无法批量操作 |
输入输出物
| 类型 | 名称 | 说明 |
|---|---|---|
| 输入 | 角色地图、需求意向清单 | 第2章产出的角色列表；来自干系人访谈、用户反馈的原始需求 |
| 输出 | 用户故事卡片（含验收条件、优先级） | 每个故事一个卡片，作为产品 Backlog 的最小条目进入迭代 |
责任边界
| 角色 | 职责 |
|---|---|
| 产品负责人 (PO) | 负责故事的价值声明、优先级标注、验收条件终审 |
| 业务分析师 (BA) | 负责编写故事正文、协调角色确认、组织验收条件评审 |
| 开发团队 | 提供技术可行性输入、估算故事点数、确认验收条件可测 |
| 测试团队 | 基于验收条件编写测试用例，执行验证并反馈结果 |
记录材料
推荐使用物理卡片或数字卡片（Jira / 禅道 / Trello），每张卡片至少包含以下字段：
故事标题： 批量导入图书信息
用户故事： 作为图书馆管理员，我想要通过ISBN批量导入图书信息，
以便将上架效率从每本3分钟降至10秒。
验收条件：
AC1: Given 管理员已登录系统，When 上传含10个ISBN的CSV文件，
Then 系统成功导入10本图书并返回“导入成功”报告。
AC2: Given 管理员上传的CSV中有重复ISBN，
When 系统处理文件，Then 跳过重复项并在报告中标记。
AC3: Given 管理员上传的CSV格式错误，
When 系统验证文件格式，Then 返回错误提示“文件格式不支持”。
优先级： P1 (Must have)
估算： 8 Story Points
备注： 依赖第三方ISBN查询API异常处理
| 异常场景 | 处理方式 | 预防措施 |
|---|---|---|
| 角色描述模糊（“用户”） | 回退到角色地图，确认具体角色类型 | 编写前先完成角色地图评审 |
| 功能描述含技术方案 | 强制使用“动词+宾语”，移除“使用XXX技术” | 故事编写应聚焦“What”而非“How” |
| 价值过于空泛（“提升体验”） | 要求量化或关联业务指标 | 价值声明必须可衡量或可观察 |
| 验收条件遗漏边界 | 补充异常路径AC（错误格式、重复、无数据等） | 参考“输入—处理—输出”六要素检查法 |
| 优先级冲突（多个P1） | 使用MoSCoW+风险矩阵重新排序 | PO 在 Sprint 计划前做价值排序 |
验收标准
一个符合规范的“用户故事卡片”必须同时满足以下六条（INVEST 原则 + 本课程扩展项）：
- Independent（独立）——故事之间无强依赖，可单独排序和交付。
- Negotiable（可协商）——故事保留讨论空间，不锁定实现细节。
- Valuable（有价值）——价值声明清晰，对业务方有可感知收益。
- Estimable（可估算）——团队能在 10 分钟内给出相对点数。
- Small（小粒度）——可在 1 ~ 3 天内完成开发+测试。
- Testable（可测试）——验收条件包含正向路径和至少 1 条异常路径。
常见反例：
❌ “作为用户，我想要系统性能更好，以便体验提升。”
——角色太泛，功能无动词，价值不可测，无验收条件，优先级无法判断。
✅ 应改为：作为 高频查询读者，我想要 图书搜索响应时间 ≤ 1.5 秒，以便 连续翻页不等待。
❌ “作为用户，我想要系统性能更好，以便体验提升。”
——角色太泛，功能无动词，价值不可测，无验收条件，优先级无法判断。
✅ 应改为：作为 高频查询读者，我想要 图书搜索响应时间 ≤ 1.5 秒，以便 连续翻页不等待。
实战要点：
1. 每个用户故事只包含 一个 功能点，便于拆分和验收。
2. 验收条件至少写 2 条：1 条正常路径 + 1 条异常路径。
3. 优先级标注应 每季度刷新一次，避免需求堆积导致优先级失真。
1. 每个用户故事只包含 一个 功能点，便于拆分和验收。
2. 验收条件至少写 2 条：1 条正常路径 + 1 条异常路径。
3. 优先级标注应 每季度刷新一次，避免需求堆积导致优先级失真。