用户故事与场景编写：用户角色、场景描述、验收条件、优先级标记
核心概念：用户故事是敏捷需求描述的最小单元，以“角色 + 目标 + 价值”结构承载用户诉求；场景描述则补充上下文与触发条件。验收条件（AC）将故事转化为可测试的判断依据，优先级标记确保研发排期与业务价值对齐。本章提供从角色识别到优先级定级的完整 SOP。
适用场景
- 需求拆解阶段：将产品需求（PRD）中的功能描述转化为独立可交付的用户故事。
- 迭代计划会前：PO 与业务方完成用户故事初稿，供研发团队评估工作量。
- 跨角色对齐会：产品、设计、开发、测试共同评审故事与场景，消除理解歧义。
- 验收测试设计：基于验收条件编写测试用例，确保故事可测、可验收。
前置条件
- 已明确产品版本目标与业务价值主张。
- 已完成用户角色（Persona）初步识别或拥有用户画像草稿。
- 已收集至少 3～5 条用户原始反馈或业务诉求记录。
- 团队已约定统一的用户故事模板与优先级定义（P0～P3）。
操作步骤
用户故事与场景编写遵循 “角色 → 场景 → 故事 → 条件 → 优先级” 五步法：
- 识别用户角色：列出与功能直接交互的所有角色（主角色、次要角色、系统角色），并为每个角色赋予唯一标识与一句话定义。
- 描述使用场景：说明该角色在什么时间、什么触发事件下、带着什么目标进入功能流程。场景应包含“前置状态 + 触发动作 + 期望结果”。
- 撰写用户故事：按标准模板
作为 <角色>，我想要 <目标>，以便 <价值>编写。一句话内不包含实现细节。 - 定义验收条件：采用 Given-When-Then 结构编写 3～5 条可验证条件，覆盖正常路径、边界与常见异常。
- 标记优先级：依据业务价值、用户影响面、技术依赖三个维度，将故事标为 P0（必达）、P1（核心）、P2（增强）、P3（远期）。
模板示例：
角色：注册用户（已登录未认证）
场景：用户首次进入“我的证件”页，看到“立即认证”入口
故事：作为注册用户，我想要完成身份证实名认证，以便解锁全部交易额度。
验收条件：
Given 用户已登录且未认证，When 用户点击“立即认证”，Then 进入身份证上传页；
Given 用户上传了清晰的身份证正反面，When 系统识别通过，Then 用户状态变为“已认证”。
优先级：P1
角色：注册用户（已登录未认证）
场景：用户首次进入“我的证件”页，看到“立即认证”入口
故事：作为注册用户，我想要完成身份证实名认证，以便解锁全部交易额度。
验收条件：
Given 用户已登录且未认证，When 用户点击“立即认证”，Then 进入身份证上传页；
Given 用户上传了清晰的身份证正反面，When 系统识别通过，Then 用户状态变为“已认证”。
优先级：P1
输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 角色 | 用户画像草稿、角色清单 | 正式用户角色定义表（含角色ID、名称、一句话描述） |
| 场景 | 用户反馈记录、业务流程图 | 场景描述卡（前置条件 + 触发事件 + 期望结果） |
| 故事 | 功能需求列表、场景卡 | 用户故事卡片（As a… I want… So that…） |
| 条件 | 故事卡片、业务规则文档 | 验收条件清单（Given-When-Then 条目） |
| 优先级 | 产品路线图、价值评估矩阵 | 优先级标记后的故事列表（P0～P3） |
责任边界
- 产品经理（PO）：负责用户角色识别、场景真实性判断、故事价值描述、优先级定级。
- 业务分析（BA）：辅助细化场景触发条件与业务规则，编写验收条件初稿。
- 技术负责人：评估故事的技术可行性与依赖关系，反馈优先级调整建议。
- 测试工程师：基于验收条件补充边界与异常场景，确保条件可测。
- 设计师：确认场景中的交互流程与角色操作路径一致。
记录材料
本章产生的所有记录统一归档至需求管理平台（如 Jira / Confluence / 飞书文档），每个用户故事卡片至少包含：
- 角色定义 ID + 名称
- 场景描述（前置 + 触发 + 期望）
- 完整用户故事文本
- 3～5 条验收条件（Given-When-Then）
- 优先级标记（P0 / P1 / P2 / P3）
- 关联的 PRD 章节编号或功能模块名
异常处理
| 异常场景 | 处理措施 |
|---|---|
| 角色冲突：同一用户在不同场景下行为矛盾 | 拆分为两个独立用户角色，分别定义场景与故事 |
| 故事包含实现细节（如“点击蓝色按钮”） | 退回给 PO 重写，强制使用“我想要 <业务目标>”句式 |
| 验收条件过多（超过 7 条） | 将非核心条件降级为“补充验证清单”，故事卡片只保留关键 5 条 |
| 优先级争议：PO 与技术负责人无法达成一致 | 引入价值/成本二维矩阵量化评分，以评分结果定级 |
| 场景缺失关键异常路径 | 测试工程师在验收条件中补充“Given 异常状态”条目，并回写给 PO 确认 |
验收标准
完成本章输出的用户故事卡片集，需满足以下全部标准方可进入研发排期：
- 每个用户故事包含且仅包含一个 明确的用户角色（角色 ID 可追溯至角色定义表）。
- 每个故事都配有 独立的场景描述，包含前置条件与触发事件。
- 故事文本严格遵守 As a… / I want… / So that… 格式，不出现 UI 元素或技术术语。
- 验收条件不少于 3 条，且至少覆盖 1 条正常路径 + 1 条边界条件 + 1 条异常场景。
- 优先级标记清晰，P0 故事不超过总故事数的 25%，P3 故事有明确的“延后交付”备注。
- 所有故事卡片已与 PRD 对应章节建立 双向链接，可追踪。
常见误区：
· 将“用户故事”写成“功能描述”，缺少价值从句（So that…）。
· 验收条件写成“系统应该…”而不是“Given-When-Then”可执行语句。
· 优先级仅凭主观判断，未使用价值/成本矩阵进行量化校准。
· 将“用户故事”写成“功能描述”，缺少价值从句（So that…）。
· 验收条件写成“系统应该…”而不是“Given-When-Then”可执行语句。
· 优先级仅凭主观判断，未使用价值/成本矩阵进行量化校准。