4. 书写用户故事的标准格式

4.1 为什么需要标准格式？

用户故事（User Story）最早出现在极限编程（XP）实践中，目的是用最精简的卡片记录需求核心。但在实际协作中，团队发现缺乏统一结构会导致理解偏差、验收模糊、价值丢失。“As a… I want… So that…” 三要素格式被广泛采纳，因为它强制回答了三个根本问题：谁在用、要做什么、为什么做。没有标准格式的故事，容易退化为功能清单，失去用户视角和价值锚点。

4.2 三要素深度解析

标准格式中的每一个要素都不是可有可无的装饰词，它们分别承担不同的语义职责：

4.3 字段结构全景：从核心到扩展

标准三要素构成用户故事的“骨架”，但在真实产品开发中，还需要附加字段来支撑排期、验收和协作。下面是一张完整的字段结构表，核心字段必须写，扩展字段按场景选用。

4.4 示例拆解：从用户访谈记录到标准化故事

下面演示一段真实的用户访谈原始记录，如何通过三步拆解，输出符合标准格式的用户故事及扩展字段。

步骤 1：原始访谈片段

受访者：李婷（连锁药店采购经理）
“我们门店经常出现某个药突然卖光了，等发现的时候再下单已经来不及了，
物流至少要三天。我希望系统能在库存低于安全线的时候直接推送到手机上，
不用我每天登录后台去翻。要是能按品种分别设置预警线就更好了。”  

步骤 2：提炼三要素

• As a → 采购经理（连锁药店）
• I want → 在手机端接收库存预警推送，并能为不同品种单独设置预警线
• So that → 能第一时间响应低库存，避免门店断货，减少紧急调货成本

步骤 3：补全扩展字段

4.5 五个最常见的格式错误

1. 角色过于笼统：“用户”“客户”等宽泛角色无法区分不同场景，应具体到“新注册的券商户”“有三个月以上账期的批发商”。
2. 功能写成了界面操作：“点击提交按钮”改为“提交审批单”；“在下拉框中选择地区”改为“指定配送区域”。
3. 价值写成了团队目标：“以便系统功能完善”或“以便通过验收”不是用户可感知的价值，应写“节省人工对账时间”“减少客户投诉”。
4. 一句话塞多个需求：“I want 查看订单并导出和打印”应拆成两个故事，每个故事独立交付和验收。
5. 遗漏验收标准：没有 AC 的故事无法确认“做完”的标准，易导致返工。至少写 1~3 条可测试条件。

4.6 本章交付物模板：用户故事卡片

在 PRD 中，每一条用户故事建议用卡片式模板呈现，便于评审、排期和追溯。下面是一个可直接复用的标准模板结构。

用户故事编号：US-042
标题：手机端库存预警推送
———————————————
As a 采购经理
I want 在手机端接收库存预警推送，并能为不同品种单独设置预警线
So that 能第一时间响应低库存，避免门店断货
———————————————
验收标准（AC）：
1. 预警推送在库存低于设定线后 5 分钟内到达手机通知栏
2. 每种商品可独立设置预警线（整数，单位：盒）
3. 预警列表显示：商品名、当前库存、预警线、预估断货天数
4. 点击推送消息直接跳转到该商品的库存详情
————————————————
优先级：P0  |  估算：5 SP  |  迭代目标：Sprint 6
依赖：库存基础数据服务（已完成）/ APP 推送通道（需对接）
关联访谈：2025-03-12_李婷_采购经理